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 <r...@debian.org>:
> Guillem Jover <guil...@debian.org> 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
