Debian Bug report logs - #950440
debian-policy: Confusing conflation of Essential:yes w/ Priority:required

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Guillem Jover <[email protected]>

To: [email protected]

Subject: debian-policy: Confusing conflation of Essential:yes w/ Priority:required

Date: Sat, 1 Feb 2020 19:17:56 +0100

Package: debian-policy
Version: 4.5.0.0
Severity: normal

Hi!

This was brought up on debian-devel, and I think it needs to be
updated/corrected in the policy manual:

On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote:
> On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote:
> > Johannes Schauer writes:
> > > My advice would also be to switch from debootstrap to mmdebstrap because the
> > > latter is able to create a chroot with only Essential:yes packages in it while
> > > debootstrap includes Priority:required packages as well. Alternatively,
> > > debootstrap could gain a variant only installing Essential:yes packages and
> > > their dependencies (why doesn't it have that already?).
> > 
> > Debian doesn't support systems that don't have "required" packages
> > installed. So buildds should have them installed.
> 
> If these statements are based on the policy quote below, then I do
> not agree. I don't see why e2fsprogs would need to be installed on
> a chroot, as long as there's nothing depending on it, for example.
> 
> > Policy states:
> > "Removing a required package may cause your system to become totally
> > broken and you may not even be able to use dpkg to put things back, so
> > only do so if you know what you are doing."
> 
> That seems wrong, or inaccurate at best. dpkg should never depend on
> anything that is not part of the pseudo-essential set (strictly
> speaking only Essential:yes + awk-virtual), or that it depends on
> explicitly. So as long as a package has not been forced out, dpkg
> must work.
> 
> Removing a required package (that is not Essential:yes) might indeed
> render your system broken, but what broken means or in what context is
> not qualified there. This could apply to systems that get booted for
> example, but not to chroots. A package that relies on another package
> that is Priority:required and not Essential:yes, and that it does not
> depend on, is just broken.
> 
> Here's the current list of these packages on my system:
> 
>   $ aptitude -F '%p' search '~prequired !~E'
>   debconf
>   e2fsprogs
>   gcc-10-base
>   gcc-9-base
>   libpam-modules
>   libpam-modules-bin
>   libpam-runtime
>   mawk
>   mount
>   passwd
>   tzdata
> 
> And most of these are actually part of the pseudo-essential set
> anyway, and cannot be removed w/o force.
> 
> That passage in policy might have made sense some time ago, when
> Priority:required almost matched the pseudo-essential set, and when we
> didn't have a separation of "dpkg-essential" and "boot-essential".

Regards,
Guillem

Message #10 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: Guillem Jover <[email protected]>

Cc: [email protected]

Subject: Re: Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required

Date: Mon, 19 Sep 2022 21:20:33 -0700

Guillem Jover <[email protected]> writes:

> This was brought up on debian-devel, and I think it needs to be
> updated/corrected in the policy manual:

> On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote:
>> On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote:

>>> Policy states:
>>> "Removing a required package may cause your system to become totally
>>> broken and you may not even be able to use dpkg to put things back, so
>>> only do so if you know what you are doing."

>> That seems wrong, or inaccurate at best. dpkg should never depend on
>> anything that is not part of the pseudo-essential set (strictly
>> speaking only Essential:yes + awk-virtual), or that it depends on
>> explicitly. So as long as a package has not been forced out, dpkg must
>> work.

>> Removing a required package (that is not Essential:yes) might indeed
>> render your system broken, but what broken means or in what context is
>> not qualified there. This could apply to systems that get booted for
>> example, but not to chroots. A package that relies on another package
>> that is Priority:required and not Essential:yes, and that it does not
>> depend on, is just broken.

I agree with this analysis, and we shouldn't be saying things about dpkg
that aren't true.

What Policy says right now is:

    Packages which are necessary for the proper functioning of the system
    (usually, this means that dpkg functionality depends on these
    packages). Removing a required package may cause your system to become
    totally broken and you may not even be able to use dpkg to put things
    back, so only do so if you know what you are doing.

    Systems with only the required packages installed have at least enough
    functionality for the sysadmin to boot the system and install more
    software.

The second paragraph seems roughly correct.  The first paragraph is
clearly at least partially false.  What should it say instead?  I'm not
sure the second paragraph is enough.  I feel like we should stress that
you may put your system into a surprising state by removing required
packages, and may have difficulties recovering because standard tools are
missing, even though dpkg should continue to wrok.

Do you have any suggestions for what an accurate statement would be?

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

Message #15 received at [email protected] (full text, mbox, reply):

From: Chris Hofstaedtler <[email protected]>

To: Russ Allbery <[email protected]>, [email protected]

Cc: Guillem Jover <[email protected]>

Subject: Re: Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required

Date: Sun, 18 Dec 2022 15:34:28 +0100

On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote:
> Here's the current list of these packages on my system:

I'll note that this list is probably missing `apt`, which seems to
be Priority: required but not Essential: yes.

* Russ Allbery <[email protected]>:
> Guillem Jover <[email protected]> writes:
> > On Fri, 2020-01-17 at 12:21:11 +0100, Guillem Jover wrote:
> >> On Fri, 2020-01-17 at 11:12:50 +0100, Ansgar wrote:
> 
> >>> Policy states:
> >>> "Removing a required package may cause your system to become totally
> >>> broken and you may not even be able to use dpkg to put things back, so
> >>> only do so if you know what you are doing."
> 
> >> That seems wrong, or inaccurate at best. dpkg should never depend on
> >> anything that is not part of the pseudo-essential set (strictly
> >> speaking only Essential:yes + awk-virtual), or that it depends on
> >> explicitly. So as long as a package has not been forced out, dpkg must
> >> work.
> 
[..]
 
> I agree with this analysis, and we shouldn't be saying things about dpkg
> that aren't true.
> 
> What Policy says right now is:
> 
>     Packages which are necessary for the proper functioning of the system
>     (usually, this means that dpkg functionality depends on these
>     packages). Removing a required package may cause your system to become
>     totally broken and you may not even be able to use dpkg to put things
>     back, so only do so if you know what you are doing.
> 
>     Systems with only the required packages installed have at least enough
>     functionality for the sysadmin to boot the system and install more
>     software.
> 
> The second paragraph seems roughly correct.  The first paragraph is
> clearly at least partially false.  What should it say instead?  I'm not
> sure the second paragraph is enough.  I feel like we should stress that
> you may put your system into a surprising state by removing required
> packages, and may have difficulties recovering because standard tools are
> missing, even though dpkg should continue to wrok.
> 
> Do you have any suggestions for what an accurate statement would be?

It would seem both Priority: required and important are not very
well defined, specifically when Debian ought to be a "Universal OS".

For Priority: required, I would suggest changing the definition,
like so:

``required``
    Essential packages, necessary for the proper functioning of the
    system (possibly because dpkg functionality depends on these
    packages).
    All packages in this priority therefore must have the
    ``Essential`` control field set, see :ref:`s-f-Essential`.


This shrinks the "required" set and reduces confusion. Anything not
Essential should not be in there.
I think this would be fine from a policy view point? If downgrading packages
from required to important causes problems for debootstrap, it would seem its
time for meta-packages describing the to-be-installed package sets per Debian
release?

I see advantages in many areas:

1) We all can stop thinking about packages being required but not Essential.
"What is the difference?" After this change we can clearly say: no difference
at all.

2) truly minimal chroots can stop installing apt. This may seem impossible at
first but apparently the sbuild unshare backend does not need apt anymore in
the chroot. This would settle discussions about Priority: required packages
"unintentionally" being installed in such chroots, and accidentally used as
"hidden" Build-Depends.

3) For "typical" desktop and server installs (probably) nothing would change.
Highly customised (think automatically managed) server installs may choose to
install less packages (example: e2fsprogs, passwd, possibly debconf).

4) Additional non-traditional usecases can tailor their installs in a better
supported way. They probably do this today, just in an unsupported way.

5) For the archive at large it seems like we need very few changes to do this.


Here is a quick list of possibly affected packages, plus my short
analysis for each one. Grouped in to groups of ascending "difficulty".


Easy
~~~~

Package: debconf
Version: 1.5.80
Priority: required

Many r-depends. I expect packages using debconf to depend on it.
Could become Priority: optional?


Package: mawk
Version: 1.3.4.20200120-3.1
Priority: required

base-files Pre-Depends awk, mawk Provides awk
Could become Priority: optional?


Package: libpam-modules
Version: 1.5.2-5
Priority: required

login Pre-Depends on libpam-modules, libpam-runtime
Could become Priority: optional?


Package: libpam-modules-bin
Version: 1.5.2-5
Priority: required

libpam-modules Pre-Depends libpam-modules-bin
Could become Priority: optional?


Package: libpam-runtime
Version: 1.5.2-5
Priority: required

login (Essential) Pre-Depends on libpam-modules, libpam-runtime
Could become Priority: optional?


Package: mount
Version: 2.38.1-4
Priority: required

sysvinit-core, systemd depend on mount.
Could become Priority: optional.


Packages becoming less protected
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Package: e2fsprogs
Version: 1.46.6~rc1-1+b1
Important: yes
Priority: required

No "commonly installed" packages seem to depend on e2fsprogs. Seems similar to
how tools for other filesystems (xfs, btrfs, ...) are not
essential/required/important.
New installs can get this either from d-i explicitly installing it if an
ext2/3/4 partition is present, or just as part of Priority: important/standard?


Package: passwd
Version: 1:4.13+dfsg1-1
Priority: required

Few r-depends. Note that passwd mostly provides functionality to change
user/group definition files.  Maybe the binaries are truly uninteresting for
maintainer scripts - otherwise more depends would exist?
Priority important seems to truly fit.


Package: tzdata
Version: 2022f-1
Priority: required

Some r-depends. Apparently timezone data is considered optional for many
things?
Priority: important would suit it well?


Special
~~~~~~~

Package: apt
Version: 2.5.4
Priority: required

apt is probably the interesting special case. Removing apt seems to be a viable
task in some increasingly popular usecases (containers, other r/o deployment
targets).

I hope apt treats itself as Essential, so removing is not "easy" or possible
by accident. Anyway, if we document things have to work without Priority: required,
it should be possible (and supported!) to reinstall apt with a simple dpkg -i.


Chris

Message #20 received at [email protected] (full text, mbox, reply):

From: Santiago Vila <[email protected]>

To: Chris Hofstaedtler <[email protected]>, Russ Allbery <[email protected]>, [email protected]

Cc: Guillem Jover <[email protected]>

Subject: Re: Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required

Date: Mon, 2 Jan 2023 14:44:58 +0100

El 18/12/22 a las 15:34, Chris Hofstaedtler escribió:
> Package: mawk
> Version: 1.3.4.20200120-3.1
> Priority: required
> 
> base-files Pre-Depends awk, mawk Provides awk
> Could become Priority: optional?

I can answer for that one. A long time ago, we decided to ensure
that some implementation of awk was always present in the system,
making awk to be both "essential" and "virtual". The Pre-Depends
of base-files on awk (being base-files essential itself) is the way
to implement such assurance that there is always some awk installed.

The rationale is that we made perl essential as an available
scripting language (via perl-base), and not doing the same
with "good old awk" as an essential scripting language would be awkward.

The mawk package has priority required so that deboostrap does not have to
"decide" which awk to install in a new system.

btw: I'm not sure if this bug is related or not with the fact that debootstrap
installs all required packages by default. I'd like to make a policy proposal
saying tools like deboostrap should try not to install packages which are
not build-essential. Does anybody remember if there is already a debian-policy
bug for that?

[ For the purpose of achieving sane chroots, we don't need to modify so much priorities ].

Thanks.

Send a report that this bug log contains spam.