Bug#954794: New packages must not declare themselves Essential
On Wed, 2020-09-30 at 18:34:06 -0700, Jonathan Nieder wrote:
> Josh Triplett wrote:
> > Jonathan Nieder wrote:
> > > Josh Triplett wrote:
> > > > This change does not propose eliminating the concept of Essential, nor
> > > > does it propose that any specific package become non-Essential.
> > >
> > > I think I'd be more supportive of this change if it did. Freezing the
> > > current essential set in time feels oddly unpragmatic. If we had a
> > > plan, even one that would take a while, to shrink the essential set,
> > > then it would be more likely to feel worth the cognitive load.
I'm in full support of trying to reduce the essential set, and this is
something we have already been trying to do for a while now:
https://wiki.debian.org/Proposals/EssentialOnDiet
https://wiki.debian.org/BusterPriorityRequalification
I also do not see the need to disallow adding new stuff to it if need
be. I think there's enough resistance in place that proposing that on
debian-devel would be met with quite some skepticism, *but* in case it
is needed, it would seem odd to do it anyway, even if policy disallows
it.
> > Long-term, I'd like to see that happen. But I'm a huge fan of
> > incremental steps; defining the problem as "eliminate Essential" makes
> > it both difficult enough and controversial enough to make it unlikely to
> > happen at all. Right now, the first step is "let's not let the problem
> > get any worse, and let's ensure that any new package that might have
> > otherwise used Essential must instead get packages to add a dependency".
> Even so, some *rough* consensus on the plan is very useful for helping
> people evaluate that first step. It also gives people confidence that
> it can still move forward even if some people involved no longer have
> time to carry it forward themselves. In this example, I think we
> agree about the ideal first (freeze the current Essential set) and
> last (eliminate Essential) steps but we don't have a clear picture of
> what happens in between. That makes it hard to be comfortable with
> the first step because there's no reason to be confident that we'll
> get any further than that.
While the idea of completely getting rid of the Essential:yes concept
has been floated around in the bootstrapping and multiarch circles,
and seems like an interesting idea, I think it currently has too many
problems to be entertained.
Several of the Essential:yes properties [P] would need to be preserved
somehow for the packaging system to be able to operate as of now. Making
that marking implicit (some kind of lore) seems worse, than the current
explicit one, because the Essential field does not get involved much in
the package system operations anyway, it's more of a contract to be
honored by *maintainers*! Having to add Pre-Depends to tons of packages,
would probably substantially strain our dependency resolvers. Maintainer
scripts in at least the essential set are another problematic area,
so they would need to be reduced substantially, or eliminated
completely [B][D].
[P] <https://lists.debian.org/debian-dpkg/2020/03/msg00002.html>
[B] <https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap>
[D] <https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging>
> If we don't have a rough plan, then the current state already seems
> okay: whenever someone proposes adding new Essential functionality, we
> can discuss it on debian-devel and the most likely outcome is that it
> gets rejected.
I think there are some rough plans for some of the problematic pieces,
but otherwise this seems rather premature, and I concur that the
current state seems fine.
> Some next steps that would make me more comfortable with an explicit
> freeze on Essential:
>
> - document how to mark a package as "not safe in normal circumstances
> to uninstall" (such as apt and systemd-sysv). Is "Priority:
> important" enough or should one use more? As a package maintainer,
> how do I mark a package as something that a user would never want to
> deinstall in normal circumstances?
This is already supported with the Protected (old Important) fields,
and was implemented precisely to make it possible to split the
essential set into its different facets.
<https://wiki.debian.org/Teams/Dpkg/Spec/ProtectedField>
> - some rough idea about how to find undeclared dependencies. Do we
> do an NMU to add currently Essential packages as Pre-Depends on all
> packages and then unmark them as Essential and let package
> maintainers sort it out? Is there some autodetection we can do
> using autopkgtest?
Not all packages need Pre-Depends on currently Essential:yes packages,
but this would require careful consideration. But as mentioned above,
having to increase the amount of Pre-Depends relationships could make
our dependency resolvers and upgrades unhappy.
Trying to detect dependencies is going to be tricky, given that most
of the essential set are callable interfaces, which need to be checked
within scripts calling those tools, or compiled code doing that while
possibly composing tools names are run-time, etc. Using a full code
search would be the usual approach, but that might not be scalable
depending on the dependency.
> - some rough idea about what to do with packages from outside the
> Debian archive. Do we provide a way to declare implicit Pre-Depends
> for everything from a particular archive?
I don't think we usually take external packages into account TBH,
besides letting our usual one stable release gap in between.
> To be clear, I'm not saying we need to commit to a plan (and I'm
> certainly not saying it should be documented in policy), but a rough
> sense of whether this seems possible and whether there are people
> interested in moving it forward would help build consensus for the
> first step.
Making it possible (or more explicit) in policy to remove packages from
the essential set might be worthwhile by for example at least covering
that some of the requirements do not need to be met while those removal
transitions are taking place, and that those transitions need to be
discussed in debian-devel, but then we have already been doing that
w/o much of a fuss anyway, so…
Thanks,
Guillem
Reply to: