David Prévot:
Hi,
[...]
Hi,
Thanks for working on this issue.
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.
[...]
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
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.
As for 3: I have no concerns with the dependency order.
Once again, thanks for working on this issue. Please clarify what
exactly was meant with "opt-out" and whether the opt-out only need to
apply to essential/pseudo-essential packages.
Best regards,
Niels
