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

Full log

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

Received: (at 950440) by bugs.debian.org; 18 Dec 2022 14:34:34 +0000
From [email protected] Sun Dec 18 14:34:34 2022
X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
	(2021-04-09) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-114.2 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER,
	HAS_BUG_NUMBER,HAS_PACKAGE,SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY,
	USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST autolearn=ham
	autolearn_force=no version=3.4.6-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 19; hammy, 150; neutral, 307; spammy,
	0. spammytokens: hammytokens:0.000-+--debianpolicy,
	0.000-+--debian-policy, 0.000-+--allbery, 0.000-+--Allbery,
	0.000-+--Hx-spam-relays-external:311
Return-path: <[email protected]>
Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:45742)
	from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=stravinsky.debian.org,[email protected] (verified)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(Exim 4.94.2)
	(envelope-from <[email protected]>)
	id 1p6ukM-002fQ0-76
	for [email protected]; Sun, 18 Dec 2022 14:34:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org;
	s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:Cc:To:From:Date:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description;
	bh=BtZEphOFnrjdzMCC70e6W4iJpgJIuQcM6DvF/ofLwdE=; b=eca2dsZU3F9zskaAjRUyQNF+cb
	ruqxml/GuaqdSqE2Lzhq1vbKelAGuonIUmiZg3yax7NbQhi6c0do1zgUnWyyBzO7WXK2Y8xc7fXmE
	+wg0T7Lt02nWVxDH/9WSgR+RihPiDtHlu1TXcQ9N3+8bVm0H2ePF2NbM4bPp0f8PzuhN1aX6kY9ro
	MmnAurmz8rqQagXRrX00HtJlGEkHh/+M+2g+pJszJiCXvlya87v4R9kXYCZUcllvqb241KKcW838P
	KIASOHXrcqMzH92cDjvpbpu27mRmtjDCskUPD+LXH4Tpu55vMH5WsWA0voUuF6H7U62KYpiVO3RpL
	thetipKQ==;
Received: from authenticated user
	by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(Exim 4.94.2)
	(envelope-from <[email protected]>)
	id 1p6ukJ-000tqn-RD; Sun, 18 Dec 2022 14:34:31 +0000
Date: Sun, 18 Dec 2022 15:34:28 +0100
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
Message-ID: <[email protected]>
References: <[email protected]>
 <[email protected]>
 <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <[email protected]>
X-Debian-User: zeha

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

Send a report that this bug log contains spam.