On 12/07/26 12:56, Guillem Jover wrote:
On Sat, 2026-07-11 at 22:35:45 +0200, Gioele Barabucci wrote:
Debian's dependency system is indeed too weak to express most
interesting and useful combinations of packages in non-standard
setups.
Because Debian's dependency system is unlikely to change soon,
anybody who does something "non standard" will have to specify their
additional needs to the tool they use to build (and update) systems.
While there are scenarios where feature additions to the dependency
system would make sense, this is not one of them. The generated
dependencies are just wrong, as already explained in
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140305#20>, because
for some weird reason, they are trying to convey completely orthogonal
things (best general systemd-sysusers/tmpfiles implementations and
default init system), which makes no sense whatsoever.
This is the equivalent of trying to shoehorn the fact that GNOME is the
default graphic desktop in Debian with selecting a terminal emulator
matching that, with something like this:
gnome | gnome-terminal | x-terminal-emulator
Hi, my point was that Debian should accept that the current dependency
system is too weak to describe the desired outcome in many scenarios,
and thus it should stop shoehorning meaning where meaning should not be
found (like the order of the dependency lists or the primacy of the
first alternative). Practically speaking: let's write all dependency
lists in alphabetical order! :)
Under that understanding, the example dependency list you proposed
should (technically speaking) be totally fine. (I understand why it is
_in fact_ not, but please bear with me while I argue this position.)
If somebody does not want a specific package they should inform their
image-building tool about their preferences. They cannot rely on 1) the
fact that all package maintainer will get the order of dependency right
(sometime it is just not possible to make everybody happy) and 2) that
apt (or any other resolver) will choose the right set of packages to
install.
For example, if mmdebstrap is used to create init-less container
images (a possible and useful, but non-standard, kind of system)
then the user really should specify `--include=init-` or
`--include=init-,systemd-` to make their needs explicit, rather than
hoping that the dependency chain that happens to be calculated by
apt that day will not include systemd.
Err, no? As also mentioned before, the way to create such thing would
be to use --variant=minbase or --variant=buildd for example. The
proposed command-line options are just a workaround for the currently
broken dependencies, which I'm surprised are even being proposed. :/
To the best of my understanding, `--variant=` in debootstrap and
mmdebstrap only changes the base set of packages to install; it does not
influence the negative set of packages that should not be installed, not
even as transitional dependencies (I don't think deboostrap even have
the concept of negative set of packages, but that is another story).
In other words, `--variant=minbase` may still pull in systemd (or any
other init system) as soon as one of the packages to be installed have
it in its (optional/alternative) dependencies.
(Here "init system" is just a placeholder for "any dependency that is
undesirable for the task at hand".)
Instead I think it's going to be way more
productive, motivating and fun, to work on just making these commands
irrelevant, so that then when we do not need them, the dependencies will
simply disappear. Which I think it's what I'm going to be focusing my
energy on.
Agreed. But shouldn't this be discussed on d-devel@ or a separate bug
report?
Regards,
--
Gioele Barabucci
