Hi!

I was updating a chroot, and I got systemd pulled in automatically due
to the dh_installtmpfiles misc:Depends values.

The order seems wrong, because if the system already uses systemd then
the systemd dependency does not need to be first, but if the system does
not use it (or does not need any init system at all), having it first
will pull it in, which in case of chroots, that's a significant size
and dependency increase.

So the small implementations should go first, and the last one should
be systemd.

This applies as well to dh_installsysusers.

Thanks,
Guillem

Guillem Jover:

Those who cannot remember the past are condemned to repeat it. And I
forgot #1017441 - that is on me.

Since there  are virtual dependencies involved, the best I can do:

    `systemd-standalone-tmpfiles | systemd | systemd-tmpfiles`

Which means only one of the small implementations comes first anyway.


But even then, I think the main problem here is that we are trying to
express different defaults for different cases via the dependency
system. The dependency system is not built for that, so no matter what I
do, the order will be wrong for some case. Namely, we are trying to solve:

  * The `systemd` is the default implementation for any Debian bootable
    system that support `systemd`

  * We generally want `systemd-standalone-tmpfiles | systemd-tmpfiles`
    for other systems (chroots, containers, etc.)


Which means the choice must be resolved outside `debhelper`'s dependency
clause. That falls on tools like `debootstrap` and `mmdebootstrap`
(which is why I am CC'ing josch). As I recall, `mmdebootstrap` just
pulls the first option and no order can solve both cases at the same time.


I have a feeling there is no "one size fits all" here. If I use the
current order, some are unhappy and if I swap someone else will be unhappy.

This is not were I want to spend my volunteer energy, so if we conclude
there is indeed no "one size fits all" I will hand it over to the
tech-ctte to make the call.
   In my view, it would clearly fit the bill of being a technical issue
that affects multiple packages with no clear "owner" of the problem. It
would also allow me to reduce this to a regular agreed dependency - even
if it is agreed by authority rather than organically grown.


Best regards,
Niels

* Niels Thykier <niels@thykier.net> [260618 08:45]:

I think in the past it was always concluded that the orders and
defaults that get expressed in packages and control files are for
the "default installation" (whatever that is, but supposedly a
single user unix machine possibly with a graphical desktop), and
everyone else has to make local adjustments.

I don't like this, but that seems to be the general consensus.

Ideally we could tell installation-like tools what the intended
usecase of the Debian installation is, but outside of d-i I'm not
aware of anything there. Ideally this approach could be shared
between different tools, so not each and every tool has to reinvent
the wheel.

Maybe some metapackages would be a first step. They could pick/force
the tmpfiles and sysusers providers.

Chris

Hi!

I'm not sure why the virtual package is a concern when not being the
first alternative, as that's what usually trips over some tools.

I don't really see the problem here, as we already have such selection
mechanism in place. This is done via the init metapackage, which
correctly pulls in systemd-sysv as the default init system (in contrast
to just systemd). And AFAICT, whether to include or not an init system
is also already supported by the various bootstrappers, via their
"variant" support or similar.

I think there's a big difference between an init system or any other
component that is expected to be already in place for the relevant
kinds of systems (init for bootable ones), versus a random service or
specific functionality provider where we have multiple alternative
implementations but have decided on a default one. In the latter case
I agree that we should express the default via the dependency system
because if you need that service and it's not going to be already
installed something needs to select it.

But for something like an init system the default is either already
installed or if is not (because no init system makes sense here or
another one has been selected) then I don't think it makes sense to
pull one in.

And in addition this seems to be conflating what init system to default
to, with a specific tooling implementation that can be fulfilled by
systemd in particular (which is not enough to provide an init system
anyway). So this concern seems a bit weird to me.

Thanks,
Guillem

Niels Thykier:
Coming back to this bug again, I believe I exceeded my limit on this top
even before I sent my previous email, and that is entirely on me.
Apologies for that. I am done with this topic, and mostly just want to
never come back to this again. However, in the interest in failing in a
"somewhat" constructive manner, I will offer the following option:

I will take **one patch** (or, at your option, an MR) that spells out
the dependencies as you (general sense, "you") believe them to be
correct. I will merge it as long as it is a valid patch that updates all
cases of the dependency - with no questions asked to order.
   It will be a patch or MR, so there is *no* interpretation of the
desired change on my side. Interpretation would require more than
minimal energy and I am not offering that.

If it lands any kind of controversy on the topic of the order, either
the patch provider deals with it or the tech-ctte deals with it. Patch
provider's call, defaulting to tech-ctte unless otherwise stated.
   If it is controversy is all in my head, the patch will unblock us and
no further action is necessary from anyone. If there is a controversy,
it will be flushed out and will delegated to someone that is not me,
which is what I would need in that situation.

That is what I am willing to offer at this point on this topic. I am
literally exhausted with `systemd` dependency discussions in `debhelper`.

On a closing note, I would like to stress that this is all about the
topic and nothing about the involved parties nor our relationship.

Best regards,
Niels

Control: severity -1 serious
Control: tags -1 ftbfs
Control: affects -1 src:restorecond src:selinux-python src:mcstrans src:gimp src:kig
Control: notfound -1 14.1
Control: found -1 14.2
Control: block 1130323 by -1

The relevant change was in 14.2, if 14.1 was intentional please say so.

I am raising the severity due to the following:

https://buildd.debian.org/status/logs.php?pkg=gimp&ver=3.2.4-3

...
Unpacking libtss2-tcti-cmd0t64:amd64 (4.1.3-6) ...
dpkg: dependency problems prevent configuration of libtss2-tcti-cmd0t64:amd64:
 libtss2-tcti-cmd0t64:amd64 depends on tpm-udev (>= 4.1.3-6); however:
  Package tpm-udev is not configured yet.
 libtss2-tcti-cmd0t64:amd64 depends on libtss2-mu-4.0.1-0t64 (>= 3.0.1); however:
  Package libtss2-mu-4.0.1-0t64:amd64 is not configured yet.

dpkg: error processing package libtss2-tcti-cmd0t64:amd64 (--configure):
...


What happened is that libselinux got recompiled with the new debhelper
  Depends: systemd | systemd-standalone-tmpfiles | systemd-tmpfiles,...
resulting in a circular dependency
  libselinux1 -> systemd -> libmount1 -> libselinux1


cu
Adrian

CCing the libselinux maintainer, since one option that's separate from
the wider debhelper question might be for it to sed that dependency out
of misc:Depends.  After all, it apparently didn't have any such
dependency before this change, and libselinux1 is special due to being
pseudo-Essential, so this is a little different from the general
question of what order the alternatives ought to go in.

Thanks to Jochen Sprickerhof, here's an easy local reproducer:

   mmdebstrap --variant=apt --chrooted-customize-hook="sed -i 's/testing/unstable/' /etc/apt/sources.list; apt -Uy upgrade" testing /dev/null

The postinst didn't call systemd-tmpfiles unconditionally before.

See #1140654 for background why your suggestion is not an option.

cu
Adrian

Maybe not exactly as I wrote it, but there are clearly other options
that the libselinux maintainer could potentially use to unblock testing
→ unstable upgrades.  For example, since it's pseudo-Essential, it might
be reasonable for libselinux1 to avoid using dh_installtmpfiles and
instead copy the previous dh_installtmpfiles postinst code into its
postinst and install the tmpfiles.d snippet manually.

The status quo ante bellum was that for many years no dependency was
emitted by debhelper, and the postinsts checked for systemd-tmpfiles
before calling it.

If we need a short-term workaround because better solution is not
available, then reverting debhelper to that state is much better
than asking maintainers to workaround it.

cu
Adrian

unstable chroots (both cowbuilder and sbuild) can't be upgraded.


Cheers,
gregor

#v+
autopkgtest [00:51:16]: test autodep8-perl-build-deps: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
  libtss2-esys-3.0.2-0t64 : Depends: libtss2-tcti-device0t64 but it is not going to be installed
                            Depends: libtss2-tcti-mssim0t64 but it is not going to be installed
                            Depends: libtss2-tcti-swtpm0t64 but it is not going to be installed
                            Depends: libtss2-sys1t64 (>= 4.0.1) but it is not going to be installed
  systemd-tpm : Depends: libtss2-rc0t64 but it is not going to be installed
                Depends: libtss2-tcti-device0t64 but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
autopkgtest [00:51:17]: ERROR: "sh -ec
   if ! type apt-ftparchive >/dev/null 2>&1; then
     # if there is nothing in the cache, we have to update first before we can
     # install anything
     [ -n "$(apt-get indextargets 2>/dev/null)" ] || apt-get update 2>&1
     DEBIAN_FRONTEND=noninteractive apt-get install -y apt-utils 2>&1
   fi
   (cd /tmp/autopkgtest.dLDORL/binaries; apt-ftparchive packages . > Packages; apt-ftparchive release . > Release)
   printf 'Package: *\nPin: origin ""\nPin-Priority: 1002\n' > /etc/apt/preferences.d/90autopkgtest
   echo "deb [ trusted=yes ] file:///tmp/autopkgtest.dLDORL/binaries /" >/etc/apt/sources.list.d/autopkgtest.list
   if [ "x`ls /var/lib/dpkg/updates`" != x ]; then
     echo >&2 "/var/lib/dpkg/updates contains some files, aargh"; exit 1
   fi
   apt-get --quiet --no-list-cleanup -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/autopkgtest.list -o Dir::Etc::sourceparts=/dev/null update 2>&1
   cp /var/lib/dpkg/status /tmp/autopkgtest.dLDORL/1-apt-update.out
   " failed with status 100
autopkgtest: failed (20).
#v-


Cheers,gregor

For that specific pain point:

https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/14

Regards,

We believe that the bug you reported is fixed in the latest version of
libselinux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1140305@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Göttsche <cgzones@googlemail.com> (supplier of updated libselinux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 11 Jul 2026 11:58:50 +0200
Source: libselinux
Architecture: source
Version: 3.11-2
Distribution: unstable
Urgency: medium
Maintainer: Debian SELinux maintainers <selinux-devel@lists.alioth.debian.org>
Changed-By: Christian Göttsche <cgzones@googlemail.com>
Closes: 1140305
Changes:
 libselinux (3.11-2) unstable; urgency=medium
 .
   [ Luca Boccassi ]
   * Move tmpfiles.d from libselinux1 to selinux-utils (Closes: #1140305)
 .
   [ Christian Göttsche ]
   * d/patches: add patches to please non-release architectures
Checksums-Sha1:
 8e27d063a5339e6191c910a5176d246cdeccd970 3130 libselinux_3.11-2.dsc
 c08e8b7effa1462e523db10849b3ca39554fbceb 52512 libselinux_3.11-2.debian.tar.xz
 172da6d0c6c2d5c25e8a0975a39d7a309f217aca 8636 libselinux_3.11-2_source.buildinfo
Checksums-Sha256:
 1b6bde259f663809baab233921422a847ade43abaf1bee2b0a330ea03ab99ba7 3130 libselinux_3.11-2.dsc
 af4785e669854701a30895fca896dbcdb89c228bd562cab21f338785a4a83542 52512 libselinux_3.11-2.debian.tar.xz
 adc7544a4febca8d9e5b0975ac5839db721ceb3aa84f552404f7e2a91acff0db 8636 libselinux_3.11-2_source.buildinfo
Files:
 99d0066fae0d2976942754a8278a0e55 3130 libs optional libselinux_3.11-2.dsc
 b0af2fa4a91b19bc3a3901b35070004e 52512 libs optional libselinux_3.11-2.debian.tar.xz
 b12a2dde721757b0e7a11e716b1aee86 8636 libs optional libselinux_3.11-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmpSGXAACgkQKGv37813
JB4+ag//fSaip4Wrt1Qyh+fYRcxP48ToGUB6MMlK50ve57WzC4kK0C2PZ5Lu6mCo
nFR3WfYvina6Px+Mqsg1jw8m/8+xraghcLxZcI4jlhgJRKmDq/Ukk5bPgJJHlDHN
RDu62njQHCjUCZhLLqML3yW1VlEHPJhspK8UGnY6YQjtAHBvw3n0Sp5q1J9p4HxY
KUDpJmd5puI3hfoot9vSJdu+p9CGrIPcfLh7ah1cMPlKCfeFe6jZ3E/DQbeFF6U/
pxnUPox052JEyJENJvPZW9DlM3UTF8hp7okXqs48OOPQhj3/KvfIHimJnXH/WGs0
qs6AhVgLRjL+VQEfkESOwBe8VmTgdU++i67QlxdBKl3iMGn9PxIrLXCgduuWwn3Y
+aA4hlosK+ikbqxjwrxXMP7Uftv2e0tjhHXI7EVK4IbjYylrA33D+Pg/qlXDDjdA
v/QSGMyVZjg40z4waE4ji99sVe6Wo2g4kJBS9jmOpRiEvh0im5MylFYaIc+xCy+x
R6nOY62nshwttTmZEotodpIzTmXz/wtribp9GefAZo6l3zXMVicXH4aRTj/IAnFn
DeLru3ZQ6hhbitasngGo6wmhit1MR87Ulzqi/ABWalVKLUg0BV8/I3OBFtkcvWHO
8nY84FiCKiezWnWQC6YiRi9jZWzrki372WFHmzZ8DpOWgtbx2vE=
=cjiN
-----END PGP SIGNATURE-----

Control: reopen -1
Control: severity -1 important

This bug cannot be fixed from within libselinux.

Thanks,
Guillem

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.

(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.

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).

Regards,

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. ]

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

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. :/

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

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.

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".)

Agreed. But shouldn't this be discussed on d-devel@ or a separate bug
report?

Regards,