Hi! [ Just to make sure, I wrote the initial report as someone who cares deeply about the Debian dependency system, the size of chroots, minimal installations in general, and has systems with systemd as init, sysvinit as init, init-less chroots, and also systems where systemd is not even available. ]
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 > (For the sake of discussion, let's define "standard" = "what > debootstrap does without extra configuration".) > > 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. :/ > One could argue (but I'm not sure if I'm ready to take this > position) that by making adjustments to the stated dependency order > we are not really helping users, just papering over issues that they > will need to address one day or another (i.e., they need to tell > their tools what non-standard configuration they really want). I strongly disagree with this premise and notion, as covered above. In any case, I reopened this report, because the change in libselinux is just a fix partially stemming from the root problem with the generated dependencies, and the bug closure was thus bogus. But besides these replies, I've got very little energy to deal with this report, less so when the tech-ctte is preemptively being invoked, as this has already become one of these draining and demotivating ones (which I guess it's unfortunately not surprising). 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. Thanks, Guillem
