Hi, Thanks to Adrian for bringing this issue to our attention and to all people participating to this bug report, bringing valuable contributions to better understand the issue, possible solutions, and their consequences, especially Simon and Helmut for the thorough analyses.
During our last meeting [0], we considered the consequences assuming
systemd-tmpfiles (the /usr/bin/ API) becoming essential [A], or not [B].
Here are the main aspects that were raised about those two issues.
A. If systemd-tmpfiles becomes essential
----------------------------------------
Consequences:
- systemd must be restructured such that libsystemd-shared becomes
coinstallable in different versions to satisfy policy requirements
about essential packages;
- systemd cannot be a policy-compliant systemd-tmpfiles provider for any
package in forky(!), unless those packages issue a dependency;
- some package (e.g. base-files) must depend on systemd-tmpfiles (with
some default alternative) to allow switching providers (like awk)
Benefits:
- purge scripts can use tmpfiles to remove their files in a declarative
way;
- one could use tmpfiles in all sorts of packages. At present, one
cannot use it in any package that systemd depends on as that would
create a loop.
B. If systemd-tmpfiles does not become essential
------------------------------------------------
Consequences:
- each binary package needs requiring tmpfiles.d to work needs to
declare the proper dependency;
- the "systemd | systemd-standalone-tmpfiles | systemd-tmpfiles"
dependency could be reordered as "systemd-standalone-tmpfiles |
systemd | systemd-tmpfiles" to avoid pulling systemd into chroots;
- debhelper can make the dependency opt-in or opt-out (opt-out =
debhelper will add the dependency when it sees a tmpfiles.d config
unless explicitly told not to add the dependency) in order to:
+ make sure the needed dependencies are in place in the common case;
+ allow maintainers to disable those dependencies if they are not
essentials for the package.
During this meeting, the consensus between the participants could
roughly be summarized as:
1. systemd-tmpfiles (the functionality) should not become essential;
2. debhelper should by default issue a dependency on systemd-tmpfiles
when it is used;
3. the systemd-tmpfiles dependency should order
systemd-standalone-tmpfiles first despite it not being the default.
0:
https://meetbot.debian.net/debian-ctte/2026/debian-ctte.2026-02-04-19.00.html
If the current consensus is acceptable, debhelper is the “only” element
that may need some update. Niels (explicitly CCed), would you agree to
implement the proposed shift in dependency order (point 3), is it easy
to implement the opt-out dependency mechanism (for point 2)?
Regards,
taffit
signature.asc
Description: PGP signature
