Bug#954794: New packages must not declare themselves Essential

[Guillem Jover <guillem@debian.org>]

On Sun, 2020-10-18 at 11:43:18 +0200, Bill Allombert wrote:
> On Thu, Oct 15, 2020 at 11:56:19AM -0700, Jonathan Nieder wrote:
> > More specifically, it's the right first three steps.
> > 
> > https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies
> > currently says
> > 
> > 	Packages are not required to declare any dependencies they
> > 	have on other packages which are marked Essential (see below),
> > 	and should not do so unless they depend on a particular
> > 	version of that package.[4]
> > 
> > 	[4] [...] If packages add unnecessary dependencies on packages
> > 	in this set, the chances that there will be an unresolvable
> > 	dependency loop caused by forcing these Essential packages to
> > 	be configured first before they need to be is greatly
> > 	increased.
> > 
> > I'd propose that as a first step we change that to
> > 
> > 	Packages are not required to declare any dependencies they
> > 	have on other packages which are marked Essential (see below),
> > 	but are permitted to do so even if they do not depend on a
> > 	particular version of that package.[4]
> 
> This is very dangerous with respect to upgrade between stable releases.
> The issue is at the time a package is made for a stable release, the
> state of Debian and Essential: yes packages is not known. It is
> unrealistic to expect Debian to plan so far in advance.
> Requiring changes to Essential packages to take into account spurious
> dependencies is too fragile.

This could refer to concerns with two opposite situations, I guess:

  - When adding new Essential:yes marks, with omitted dependencies (but
    that is already a problem with the current text). In that case
    the dependencies on the new Essential:yes should only be dropped
    after the next stable release, or packages might assume the
    presence of functionality that might not be there.
  - When removing old Essential:yes marks, with adding "excess"
    dependencies, which could possibly introduce dependency loops,
    that could break ordering assumptions in maintainer script
    execution. This can be problematic if the requirements for the
    behavior of an Essential:yes package for the affected package are
    dropped before the next stable release (work even when unpacked,
    Pre-Depends usage, etc), but otherwise it should be fine I guess.

Thanks,
Guillem