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
