RFC: No new Essential packages?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: No new Essential packages?

Josh Triplett-9
The concept of an "Essential" package seems to exist for something so
common that no package should have to declare a dependency on it.

However, 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 to add a dependency, carefully
managing a transition across Debian releases, and risking third-party
breakage.

Leaving aside the *existing* Essential packages, or any packages they
might transition into, is there a good rationale to allow *new*
Essential packages? Would it be reasonable for Policy to have guidance
suggesting that we should not introduce new Essential packages, and that
packages should use Depends or Pre-Depends as appropriate instead?

Any such guidance could make an exception for all existing Essential
packages, as well as for new packages introduced to transition from
existing Essential packages. (This policy shouldn't, for instance,
prevent Essential packages from splitting or combining.)

Does this seem reasonable?

- Josh Triplett

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Ansgar Burchardt-5
Josh Triplett writes:
> Leaving aside the *existing* Essential packages, or any packages they
> might transition into, is there a good rationale to allow *new*
> Essential packages? Would it be reasonable for Policy to have guidance
> suggesting that we should not introduce new Essential packages, and that
> packages should use Depends or Pre-Depends as appropriate instead?

I think there is a consensus that introducing new essential packages
should be avoided.

Is the current wording in Policy not sufficient?  In 3.8 Essential
packages it states "this flag must not be used unless absolutely
necessary" and later "You must not tag any packages essential before
this has been discussed on the debian-devel mailing list and a consensus
about doing that has been reached".

Ansgar

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Russ Allbery-2
Ansgar <[hidden email]> writes:

> Is the current wording in Policy not sufficient?  In 3.8 Essential
> packages it states "this flag must not be used unless absolutely
> necessary" and later "You must not tag any packages essential before
> this has been discussed on the debian-devel mailing list and a consensus
> about doing that has been reached".

I think Josh is arguing that ideally we'd slowly move towards declaring
dependencies on essential packages explicitly, so we should indicate that
in Policy and, as a first step, say that we're not adding any entirely new
functionality to the essential set if we can help it and instead asking
people to just declare explicit dependencies.

I've never liked the rule that you don't have to declare dependencies on
essential packages and would love to phase it out as much as possible (I
think even intermediate movement in that direction would be useful), but
I'd like Guillem to weigh in from a dpkg perspective to indicate whether
this makes sense to him and whether I'm missing something.

(Also, that said, having every package that contains a shell script
declare a dependency on sh | dash and every package that uses a common
shell utility declare a dependency on coreutils, despite being a nice way
to remove some special cases and make the dependency structure more
explicit, may be a bit too tedious to want to endure.)

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Josh Triplett-9
Russ Allbery wrote:
> I think Josh is arguing that ideally we'd slowly move towards declaring
> dependencies on essential packages explicitly, so we should indicate that
> in Policy and, as a first step, say that we're not adding any entirely new
> functionality to the essential set if we can help it and instead asking
> people to just declare explicit dependencies.

Yes, exactly. To be clear, I am *not* proposing that we eliminate the
concept of Essential, nor am I suggesting that any specific package
should become non-Essential; I'm suggesting that no new packages should
become Essential.

I would, roughly speaking, propose language along these lines:

"New packages must not declare themselves Essential, even if this
requires many other packages to declare explicit Depends on them.
Existing Essential packages may continue to use the Essential flag in
new versions. If an existing Essential package needs to change its
packaging structure in a way that would introduce a new package with the
Essential flag, this must be discussed on the debian-devel mailing list
and a consensus and transition strategy for doing so must be reached."

> I've never liked the rule that you don't have to declare dependencies on
> essential packages and would love to phase it out as much as possible (I
> think even intermediate movement in that direction would be useful)

I would like to work towards that as well.

> (Also, that said, having every package that contains a shell script
> declare a dependency on sh | dash and every package that uses a common
> shell utility declare a dependency on coreutils, despite being a nice way
> to remove some special cases and make the dependency structure more
> explicit, may be a bit too tedious to want to endure.)

Honestly, dash is the *last* package I would want packages to have to
declare explicit dependencies on.

However, I could absolutely imagine having debhelper supply an automatic
dependency on bash for every package containing a #!/bin/bash script,
and something similar for perl-base. I imagine that some of the embedded
Debian derivatives would appreciate that.

The packages I would personally be most interested in making
non-Essential would have relatively few packages depending on them:
- login (not necessarily needed in a chroot/container that doesn't
  support interactive logins)
- hostname (not necessarily needed at all)
- ncurses-base and ncurses-bin (not necessarily needed on systems that
  don't support interactive use).

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Bill Allombert-4
In reply to this post by Russ Allbery-2
On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote:
> I've never liked the rule that you don't have to declare dependencies on
> essential packages and would love to phase it out as much as possible (I
> think even intermediate movement in that direction would be useful), but
> I'd like Guillem to weigh in from a dpkg perspective to indicate whether
> this makes sense to him and whether I'm missing something.

This rule is vital to allow for smooth transition when essential
programs are moved from one package to another.
This is also necessary to avoid circular-Predepends which are not
supported by dpkg.
e.g. glibc need to predepends on bash because it has a maintainer script
and bash need to depend on glibc.

Cheers,
--
Bill. <[hidden email]>

Imagine a large red swirl here.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Wouter Verhelst
On Sun, Feb 02, 2020 at 01:31:14AM +0100, Bill Allombert wrote:
> On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote:
> > I've never liked the rule that you don't have to declare dependencies on
> > essential packages and would love to phase it out as much as possible (I
> > think even intermediate movement in that direction would be useful), but
> > I'd like Guillem to weigh in from a dpkg perspective to indicate whether
> > this makes sense to him and whether I'm missing something.
>
> This rule is vital to allow for smooth transition when essential
> programs are moved from one package to another.

It's not? We have programs moving from one package to another all the
time outside the set of Essential packages, and the sky isn't falling.

> This is also necessary to avoid circular-Predepends which are not
> supported by dpkg.
> e.g. glibc need to predepends on bash because it has a maintainer script
> and bash need to depend on glibc.

This, however, sure.

--
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Bill Allombert-4
On Sun, Feb 02, 2020 at 08:08:34AM +0200, Wouter Verhelst wrote:

> On Sun, Feb 02, 2020 at 01:31:14AM +0100, Bill Allombert wrote:
> > On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote:
> > > I've never liked the rule that you don't have to declare dependencies on
> > > essential packages and would love to phase it out as much as possible (I
> > > think even intermediate movement in that direction would be useful), but
> > > I'd like Guillem to weigh in from a dpkg perspective to indicate whether
> > > this makes sense to him and whether I'm missing something.
> >
> > This rule is vital to allow for smooth transition when essential
> > programs are moved from one package to another.
>
> It's not? We have programs moving from one package to another all the
> time outside the set of Essential packages, and the sky isn't falling.

Remember the libc5 to libc6 transition ?
Imagine the number of packages that would depends on bash.

Cheers,
--
Bill. <[hidden email]>

Imagine a large red swirl here.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Wouter Verhelst-5
On Sun, Feb 02, 2020 at 01:59:30PM +0100, Bill Allombert wrote:

> On Sun, Feb 02, 2020 at 08:08:34AM +0200, Wouter Verhelst wrote:
> > On Sun, Feb 02, 2020 at 01:31:14AM +0100, Bill Allombert wrote:
> > > On Sat, Feb 01, 2020 at 11:59:34AM -0800, Russ Allbery wrote:
> > > > I've never liked the rule that you don't have to declare dependencies on
> > > > essential packages and would love to phase it out as much as possible (I
> > > > think even intermediate movement in that direction would be useful), but
> > > > I'd like Guillem to weigh in from a dpkg perspective to indicate whether
> > > > this makes sense to him and whether I'm missing something.
> > >
> > > This rule is vital to allow for smooth transition when essential
> > > programs are moved from one package to another.
> >
> > It's not? We have programs moving from one package to another all the
> > time outside the set of Essential packages, and the sky isn't falling.
>
> Remember the libc5 to libc6 transition ?

Honestly? No. It's been long enough that I hadn't even heard of Debian
when it happened, let along that I would be involved (and I have been
involved in Debian since 2001).

I don't believe this is a coincidence; our processes to do such
transitions have improved vastly since those days, and I do not think
that we will have another transition as involved as the libc one.

--
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Sean Whitton
In reply to this post by Russ Allbery-2
Hello,

On Sat 01 Feb 2020 at 11:59AM -08, Russ Allbery wrote:

> Ansgar <[hidden email]> writes:
>
>> Is the current wording in Policy not sufficient?  In 3.8 Essential
>> packages it states "this flag must not be used unless absolutely
>> necessary" and later "You must not tag any packages essential before
>> this has been discussed on the debian-devel mailing list and a consensus
>> about doing that has been reached".
>
> I think Josh is arguing that ideally we'd slowly move towards declaring
> dependencies on essential packages explicitly, so we should indicate that
> in Policy and, as a first step, say that we're not adding any entirely new
> functionality to the essential set if we can help it and instead asking
> people to just declare explicit dependencies.
In this case, it doesn't seem like we'd need any new normative wording
in Policy -- I think Ansgar is right that the current text ensures that
we're not adding any new functionality to the essential set if we can
help it.

What we might need is new, purely informative wording saying that one
reason for the restrictions is that we're working towards declaring
dependencies on essential packages explicitly (if indeed that is
something we want to do, which I don't yet have a firm opinion on).

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Josh Triplett-9
On Sun, Feb 02, 2020 at 07:54:42PM -0700, Sean Whitton wrote:

> Hello,
>
> On Sat 01 Feb 2020 at 11:59AM -08, Russ Allbery wrote:
>
> > Ansgar <[hidden email]> writes:
> >
> >> Is the current wording in Policy not sufficient?  In 3.8 Essential
> >> packages it states "this flag must not be used unless absolutely
> >> necessary" and later "You must not tag any packages essential before
> >> this has been discussed on the debian-devel mailing list and a consensus
> >> about doing that has been reached".
> >
> > I think Josh is arguing that ideally we'd slowly move towards declaring
> > dependencies on essential packages explicitly, so we should indicate that
> > in Policy and, as a first step, say that we're not adding any entirely new
> > functionality to the essential set if we can help it and instead asking
> > people to just declare explicit dependencies.
>
> In this case, it doesn't seem like we'd need any new normative wording
> in Policy -- I think Ansgar is right that the current text ensures that
> we're not adding any new functionality to the essential set if we can
> help it.

I think there's value in a bit of additional verbiage, which I suggested
in a subsequent reply.

- Josh Triplett

Reply | Threaded
Open this post in threaded view
|

Re: RFC: No new Essential packages?

Sean Whitton
Hello Josh,

On Tue 04 Feb 2020 at 04:13PM -08, Josh Triplett wrote:

> I think there's value in a bit of additional verbiage, which I suggested
> in a subsequent reply.

Okay -- I think further discussion would benefit from a concrete patch
against policy.git.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment