Bug#954794: New packages must not declare themselves Essential
On Thu, Oct 15, 2020 at 11:56:19AM -0700, Jonathan Nieder wrote:
> Javier Serrano Polo wrote:
> > On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder <jrnieder@gmail.com>
> > wrote:
>
> >> Even so, some *rough* consensus on the plan is very useful for
> >> helping people evaluate that first step.
> >
> > Here is a rough plan:
> >
> > 1. Policy: Packages should declare all their dependencies, even
> > essential ones.
>
> I agree: this is the right first step.
>
> 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]
>
> [4] Functionality is rarely ever removed from the Essential
> set, but packages have been removed from the Essential set
> when the functionality moved to a different package. So when
> depending on these packages for such functionality, it is
> recommended to depend on an appropriate virtual package
> instead.
>
> Future versions of Debian policy may encourage and then
> require including explicit dependencies even for essential
> functionality. This is helpful to users putting together
> ultra-minimal systems (though Debian does not support omitting
> Essential functionality out of the box), and it means less
> work is required in case the moment comes to remove some
> functionality from the Essential set in the future.
>
> (The next two steps would be to change that from "are permitted" to
> "should", and then to "must".)
>
> What do you think?
That sounds great to me. This would mean that there'd be no policy
violation involved if someone wanted to send out patches working towards
making a package non-Essential. It's a good incremental step.
Reply to: