Bug#1141909: tech-ctte: dh_installtmpfiles-generated dependencies

Package: tech-ctte
Severity: normal
X-Debbugs-Cc: Debhelper Maintainers <[email protected]>, Luca Boccassi <[email protected]>
Control: block 1140305 by -1

I am hereby asking the Technical Committee for advice and a
decision regarding dh_installtmpfiles-generated dependencies.

This is a not a topic that started recently, see e.g. [0].

dh_installtmpfiles installs tmpfiles.d configuration files.
This is a systemd invention, but src:systemd also provides
systemd-standalone-tmpfiles for other init systems.

Every Debian filesystem has one of the following:
(S) systemd as init
(I) non-systemd init
(N) no init (e.g. chroot)

The dh_installtmpfiles status quo until trixie was:
- no package dependencies created
- systemd-tmpfiles is only called after checking for its availability

It was in the past documented that dh_installtmpfiles might only
work with (S), limiting its use in Debian.

The check for availability of systemd-tmpfiles in generated maintainer
scripts was removed in [1].

Due to breakage caused by this,[2] dh_installtmpfiles now creates a
dependency on:
  systemd | systemd-standalone-tmpfiles | systemd-tmpfiles

systemd as first option is rather huge, which is undesirable in many
situations.[3]

After libselinux got rebuilt this also created a circular dependency,
causing various breakages (e.g. on our buildds).[4]

The workaround in [5] mitigated the latter, but "A library package should
not have side effects on a system." is not a correct general statement.
When I asked whether the change might introduce a security regression
the reply that Recommends are installed by default strikes me as a rather
non-convincing argument when the change is removing a dependency, and
incorrect assumptions about what can be expected to be installed are
also not helpful (Christian and Simon had more convincing arguments
why the change is mostly harmless).
In general I became convinced that this needs the TC involved which can
also make a decision to settle the issue.

One side effect of this workaround is that a package from the essential set
now recommends selinux-utils and installs it on many systems without SELinux,
wasting space.

The previous three paragraphs are about the circular dependency issue,
the debhelper maintainer suggesting to bring this topic to the TC[6]
(also implying that a 3:1 majority is not required) due to the size
of systemd pulled in predates the circular dependency issue.

While thinking about the dependency order suggestion and possible side effects
I came up with a different solution I hereby suggest as [A] and [B] depending
on what is desirable for (N):


If it is OK that tmpfiles might not be functional in (N):

  [A]
  - dh_installtmpfiles does not create any systemd-tmpfiles dependencies.
  - systemd-tmpfiles calls generated by dh_installtmpfiles are only made after
    checking for its availability.
  - init systems must ensure that a systemd-tmpfiles implementation is available.

The implementation of the last bullet point would be addition to policy 9.3 and
filing bugs against init systems.


If tmpfiles must also be functional in (N):

  [B]
  - dh_installtmpfiles does not create any systemd-tmpfiles dependencies.
  - The systemd-tmpfiles virtual package gets added to the essential set.

An essential virtual package would be similar to awk.

It does not make sense to generate dependencies in a gazillion packages
and argue about dependency order when the end result is anyway that we
are adding a (virtual) package to the essential set.


[0] https://bugs.debian.org/1017441#49
[1] https://salsa.debian.org/debian/debhelper/-/commit/14a5fb772a78854f4e57fceae2637f9dd3a58b1c
[2] https://bugs.debian.org/1140654
[3] https://bugs.debian.org/1140305
[4] https://bugs.debian.org/1140305#30
[5] https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/14
[6] https://bugs.debian.org/1140305#25