Hi!

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

Regards,
Guillem

Guillem Jover <guillem@debian.org> writes:

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?

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

* Russ Allbery <rra@debian.org>:
[..]
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

El 18/12/22 a las 15:34, Chris Hofstaedtler escribió:

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.