Hi Niels, On Sat, Sep 26, 2026 at 12:07:06AM +0200, Niels Thykier wrote: > I want to clarify something here because I think it is unfortunate to use > the phrase "opting out of the dependency". When the discussion was referred > to the tech-ctte, the `debhelper` integration code with tmpfiles had a hard > dependency because it had been changed in 13.5 to fail closed without the > tmpfiles provider. Previously, it failed open when the tmpfiles provider was > not available (by skipping the integration code entirely). > > My best guess from here (but it is an assumption) is there is an implicit > "permanently revert the fail-closed behaviour added in 13.5" on top of the > opt-out, because removing the dependency on its own will just create bricked > packages. Bricked packages seemed universally undesirable to me and my > assumption was the best guess for what you meant instead. > > As for opt-out, I will let this simmer for a bit before I implement the > advice. It is not something I had expected. For me, the problem here is not > about "easy" but cognitive load. We introduce a feature that 2-5 packages > are likely to use, but thousands of Debian contributors will be exposed to > it (as in, will see the docs, have to evaluate whether they need it, etc.). > At the same time, not providing it means those 2-5 packages have to do their > own NIH / Cargo-cult'ing of a snippet plus hope it never need changes. > But at this time, I do not see a good solution unless we can identify the > exceptions as essential/pseudo-essential packages only. And even then, all I > have is a half-finished idea that need some time in the metaphorical pot.
Fundamentally, we wanted to recognize that there are two behaviors both of which are desirable in certain situations. In trying to explain this, I think there are actually more behaviors we should differentiate. For some packages, the tmpfiles.d functionality is required for the correct operation of the package. In such cases, we want a hard dependency and the systemd-tmpfiles being run in a way that propagates failure. The other extreme is packages adjusting the default behavior by listing exceptions to the usual cleanup rules. For instance, mmdebstrap contains such an exclusion rule only. No systemd-tmpfiles dependency is needed nor is there a need to run systemd-tmpfiles during postinst. In between, I see two more common behaviors. One such behavior is the use of tmpfiles.d in support of a systemd.service unit. In order to run the service, we need a manager process and I think it is relatively safe to assume that any non-systemd implementation of this interface would at this time also have to provide systemd-tmpfiles functionality (e.g. by depending on seedfiles). So in such cases, we ideally do not need a systemd-tmpfiles dependency: If there is no service manager, tmpfiles.d support also is not needed. Still the maintainer script needs to run systemd-tmpfiles (in a way that doesn't fail when missing unlike the earlier case). The service example bears a notable aspect. Some packages additionally install init.d scripts. Those scripts can either duplicate the tmpfiles.d functionality (in which case the catgeory remains) or rely on systemd-tmpfiles having been run before the init script is invoked (in which case, we probably are in the unconditional case). Then there are a number of non-service uses of tmpfiles.d that also are not hard requirements. For instance, openssh-client uses tmpfiles.d to turn ssh-agent setgid _ssh. This is a hardening mechanism and we'd likely want it. When systemd-tmpfiles is available, it should be run and it likely should be recommended, but maybe it shouldn't be a hard dependency. And then there exist various combinations of those behaviors. For instance openssh-client both uses it for hardening and for adding a cleanup exclusion. I now see the following sensible debhelper behaviors: 1. Dependency + run systemd-tmpfiles unconditionally 2. Recommends + run systemd-tmpfiles when available 3. No dependency + no maintainer script Let me come back to the question of what opt-out means. The optional aspect recognizes that several behaviors are sensible in different situations. There is no one size fits all here. The in/out part is about which of them is called the default. Ultimately, the selection of the desirable behavior has to be a concious choice of the package maintainer and thus has to increase the complexity of the debhelper API, because the desired behavior cannot reliably determined using an algorithm. When we recommended opt-out, we meant that the default behavior should be assuming that systemd-tmpfiles is required for the package to work. Possibly, debhelper can actually parse the tmpfiles.d files and automatically change the default behavior when all non-comment lines start with an x or X (i.e. when the tmpfiles.d snippets contain exclusions only). Does this clarify things? Helmut
