Bug#954794: New packages must not declare themselves Essential

[Jonathan Nieder <jrnieder@gmail.com>]

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.
>
> 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".

In consensus building and implementation, I agree with you: I like to
see work in incremental steps, and it's not necessary to get full
consensus for the full plan in advance.  After all, we can learn as we
go and would need to change the plan.

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.

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.

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?

- 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?

- 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?

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.

Thanks,
Jonathan