Helmut Grohne:
Hi Niels,On Sat, Sep 26, 2026 at 12:07:06AM +0200, Niels Thykier wrote:[...]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. [...]
Hi Helmut,Thanks for listing the use cases you see for when the feature should be mandatory vs. optional.
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. [...]
Thanks. What I needed was the list you provided above. I read the original statement as only had the half-hand side of the listed equations above and knew it could not be right. But I had ended at 1 & No dependency + run systemd-tmpfiles when available.
Does this clarify things? Helmut
It clarifies what I need. I still do not see why a maintainer would bother with removing this dependency outside the essential set. But perhaps it is better for me not to question what motivates the Debian volunteers to put extra burdens on themselves for what others perceive as dubious gains. So let us leave it at that. Related: @smcv, please consider my previous question as retracted.
My current consideration is to make the dependency default a new compat level to ensure people properly evaluate this new interaction. I have already reverted to the pre-13.5 behaviour (no dependency, run if available), which I intend to be the state we stay in until I am ready to deploy a solution/the compat level with those changes. I figured it was the safest of the non-ideal option as a non-opt-out dependency could cause problems for the essential set (which might require a "rush" solution) and we have had no notable issues in practice with the current configuration. I suspect smcv correctly identified that this new feature likely sets the tone for how (third-party) debhelper tools will implement tiered dependencies. For relationship substvars to be a success, I feel it is best if that API is done with care.
Thanks for the advice. From my PoV, this is now closed and I know which direction we are headed. I might not know all the steps there, but I will figure that out.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
