Bug#758234: [summary] Re: Bug#758234: transitive dependencies

[Charles Plessy <plessy@debian.org>]

[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