Paul Wise <p...@debian.org> writes: > I am missing the justification for the last paragraph of Debian Policy > section 2.5. I feel that it may have been due to a limitation of our > tools in the past and that these days there are zero downsides to this > situation (debootstrap/etc handle it fine) so we should probably remove > the paragraph from policy.
> There is also a downside to raising priorities in this way; raising the > priority of dependencies of higher-priority packages means that if > implementations of higher-priority packages change and the (now higher > priority) dependencies are no longer needed, we have to do work to > revert those changes. I think they would end up as cruft that is > forgotten about or just cause busywork that we can avoid in the first > place by not raising priority of dependencies. Yeah, that's one of the solutions to the broader problem that we were discussing on debian-policy. Gerrit was concerned that making this change would make it even harder to track changes to the size of the required, important, and standard sets than it is now, but I'm not convinced that the priority concept is the right machinery for doing that. What I think you're saying, and what I was thinking about after that discussion, is whether we should recast priorities as applying to the leaf packages that we're trying to get installed. In other words, the things we're specifically interested in having on the system would be required, important, or standard. Everything else (such as all the shared libraries) would be optional. Then calculating the size of required would mean calculating the transitive closure of packages pulled in as dependencies of required packages. I feel like this is essentially what we've been doing in past releases; we've just taken the bookkeeping step before the release of raising the priority of all the packages in that dependency tree to match the priority of the leaf package. I'm not sure there's much point in doing that, since the information is retrievable other ways. If we want, as a project, to monitor the size of the required, important, and standard sets, I feel like we should do that directly: run a cron job somewhere that remembers the previous size, calculates the new transitive closure, and mails out a report once a week or month or something listing which packages were added or removed and their sizes, as well as the total installed size of each of those sets. I think that would be more effective and more directly on point than mucking about with trying to monitor priority changes. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx4sy73x....@hope.eyrie.org
