Re: New package split of util-linux
On Thu, Jul 27, 2017 at 12:32:24PM +0200, Andreas Henriksson wrote:
> On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote:
> > But why should mount be Essential? It's useless in containers and chroots.
>
> I'm very open to making things non-essential if possible, not limited to
> only mount. (Why should bsdutils be essential for example? But how do we
> make it non-essential? Even if policy didn't forbid depending on
> essential packages, how would we even identify users that should add
> a dependency? See also #474540 for another example of this practical
> problem.)
https://wiki.debian.org/BusterPriorityRequalification has some interesting
discussion.
Making things non-Essential is indeed hard, but making them Important[1]
is easier as for most tools these two are considered synonymous.
As we're very early in Buster's cycle, a somewhat cavalier approach could
be acceptable: to degrade programs and see what breaks. It's safe for
upgrades (tools really dislike removing Important) and for new regular
whole-machine installs; only uses that might have issues are chroots
and small containers.
> I aware of but have no practical experience with the Important: yes
> field. I can only guess and hope that if we use that for mount there
> won't be any weird upgrade problems. (Help welcome to verify it!)
I've done some research, and:
* user-facing tools support Important well enough, as of Stretch:
while dpkg itself doesn't protest, frontends like apt, dselect, aptitude,
synaptic, gnome-packagekit, apper are all _too_ paranoid here. This is
actually good for ordinary users -- converting a full machine to a
container isn't exactly a common use case.
The only frontend that doesn't stop you is cupt, but with popcon vote of
23 it's not much of a concern, especially that you tend to remove Buster
packages using Buster tools.
* on the other hand, current dpkg-gencontrol does not support this field
* the Policy doesn't mention it either
Thus: it's not legal to use Important yet but there are no blockers to
have it for Buster.
If you'd like to play some more, my test packages are in:
deb http://angband.pl/debian essimp main
(-src, https), key:
wget -qO- https://angband.pl/deb/archive.html|apt-key add -
"test-essential", "test-important"
> > What about making the split at different levels of essentialness? With the
> > new Important: yes (not be confused with priority: important), this makes
> > three levels, and thus three packages:
> > * stuff that's needed on every Debian system
> > * stuff needed on every bare-metal box / "real" VM
> > * things you can go without
>
> I would be very interested to see your resulting of this splitup!
As Steve Langasek mentioned, not all containers are alike. Unlike old-style
implementations like vserver or openvz (even they let you allow ccaps
SECURE_MOUNT and BINARY_MOUNT), modern containers are a really fuzzy
concept, with a mix-and-match of chroot, cgroups, namespaces, seccomp.
But there's a pretty common set of things typical containers don't need.
They don't need to manipulate partitions, fsck, etc. That's most of
util-linux's size.
> In theory I'm not really sure there's anything matching the "stuff
> that's needed on every Debian system" criteria in src:util-linux
> if considering less usual usecases.)
Yeah but a container has a host which can rescue it, and then you can
install anything you want into the container. So it's about minimal
functionality only.
Meow!
[1]. A poorly chosen name, because of confusion with priority:important.
But AFAIK it was repurposing an ancient hidden feature rather than a new
design.
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water
Reply to: