[CCed all people who expressed themselves in #758234 (forgive me if I forgot some), and debian-boot and debian-cd (there is a question for you)]
Dear all, here is a summary of the discussion in #758234 regarding package Priorities, the way they are used, and what the Policy contains about them. (Some text is more or less directly pasted from messages in these threads). In brief, it has been proposed to relax the rule that package of a given priority can not depend on packages of a lower priority. The arguments in favor of this change are mainly about practical issues when installing Debian with the standard tools (in particular debootstrap), and the arguments against revolve mainly about keeping control of what a minimal or a default Debian system contains. Currently, maintainers of packages do not control the priority settings of their packages in the archive (the Policy is misleading on that point, and corrections are discussed in #196367). The FTP team has the final control of Priorities through an "override" file. The original proposition in #758234 is to drop the following paragraph from 2.5. Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. I hope that it will be possible to get consensual approval for that change, by giving in counterpart some guarantees about transparency regarding changes (usually increases) to the size and contents of systems installed by pulling the Required, Important and Standard packages. Arguments in favor of the change -------------------------------- The main problems caused by the current Policy (despite it is not consistently enforced) are: - The work load to promote and demote packages that are depended on by high-priority packages (not just libraries, see for instance the foo/foo-common pairs) get it if its priority is raised to important. - When excluding an Important package from a fresh system, one would still get its whole dependency chain if the Policy were fully applied. - It is sometimes un-noticed that a package leaves an Important package's dependency chain and as a consequence this package is installed for nothing. - It is hard to trace whether a package is inherently Important, or only because it is part of a dependency chain. If the proposed change is adopted, the size of standard and minimal Debian systems would be determined by following the dependency chain instead of just adding up all packages from Important or Standard priorities. Importantly, given that the current Policy is not enforced, this actually is already needed. Some alternative changes have been proposed during the discussion, in particular a) explicitly discouraging changing priorities only because a package is in a dependency chain (https://bugs.debian.org/758234#144), b) introduce safeguards regarding conflicting packages (https://bugs.debian.org/758234#173), c) keep the requirement for Required packages to not depend on lower priorities https://bugs.debian.org/758234#10). However, these variant proposals did not gain much traction compared with the original one. Regarding transparency ---------------------- It has been criticized that dependencies have been added to Important packages without enough oversight or transparency to the Project, and the current system of manually adjusting the priorities of the dependency chain is seen as one mechanism for such oversight. Thus, relaxing the rule would reduce transparency. As a replacement, manual or automated notifications have been discussed, with the following proposed recipients. - The maintainers of packages that transitively enter the Required, Important or Standard set by being depended on. - The debian-devel mailing list, like for Pre-Depends. - More directly implicated developers via mailing lists such as debian-boot and debian-cd. - The FTP team via the BTS, where change of the override file means approval. Notifications also have been criticised: some developers are not interested in or even actively filter automatically generated mails. Discussions on debian-devel are seen as inconclusive, counterproductive, or worse. Also, a member of the FTP team expressed his doubts whether this team should be telling to maintainers of high priority packages what other packages they may depend on. However, my feeling after reading this thread is that it would be hard to ignore the demand for transparency, and this transparency would be hard to achieve without notifications of some kind. Side discussions ---------------- In the course of this discussion it was proposed to merge the Optional and Extra priorities. I will post a separate summary in #759260. There was also a discussion on better defining pseudo-essential in the Policy, which made good progress (#759491). Conclusion ---------- I think that we have a chance to get a consensus on a) accepting that packages may depend on lower-priority packages if we find a satisfying way of b) keeping the relevant people informed of decisions that may change Debian's installation size. Therefore I have questions for you, and I would be especially pleased if your answers could converge into a final proposition that makes everybody comfortable. - Would a message to the relevant package maintainers be enough ? - Should the debian-boot and debian-cd mailing lists be notified as well ? - Is a message to debian-devel needed ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
