[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#954794: New packages must not declare themselves Essential



On Tue, Sep 29, 2020 at 05:23:38PM -0700, jrnieder@gmail.com wrote:
> Hi,
> 
> Josh Triplett wrote:
> 
> > Over the years, "Essential" has made it difficult to reduce installation
> > size, to reduce chroot/container size, or to coordinate various
> > transitions. Removing something from the Essential set requires tracking
> > down every package using it, adding a dependency, carefully managing a
> > transition across Debian releases, and risking breakage of third-party
> > packages outside Debian.
> 
> Interesting.  On the other side if we were to eliminate Essential
> would be bloat in the Packages file from e.g. ~every package needing
> Pre-Depends on a shell.

That seems like it'd be trivially handled by compression. I just did a
quick test, and adding "bash, coreutils, " to every single package
record would only add 10k to the entire gzip-compressed file (which is
currently 10816k, so, <0.1%). There are currently ~60k *packages* in the
packages file, so this adds, on average, about a sixth of a byte per
package.

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


Reply to: