Hi Niels, On Sat, Sep 05, 2026 at 11:25:49AM +0200, Niels Thykier wrote: > I write today because I am in the situation where I would like to do a > backport of `debhelper` soon (for compat 14 support / #1141097) and the > discussed change is currently sid/testing-only but not limited to compat 14.
thank you for reaching out. I'm sorry for the long silence. Vaction is no longer a suitable explanation here. The topic is scheduled for our Thursday meeting. > Therefore, I would instead like a quick / informal advice on a narrower part > of this topic, namely whether I should revert the changes until we arrive at > a resolution? Concretely, the commits to be reverted would be > 14a5fb772a78854f4e57fceae2637f9dd3a58b1c + https://salsa.debian.org/debian/debhelper/-/commit/14a5fb772a78854f4e57fceae2637f9dd3a58b1c dh_installtmpfiles: add dependency on tmpfiles implementation > d663063ee93ea115cca5d7e36d6cbcad0e126efe. https://salsa.debian.org/debian/debhelper/-/commit/d663063ee93ea115cca5d7e36d6cbcad0e126efe dh_installsystemd: also add tmpfiles deps in compat 12 > Another way to frame this question might be: Would it make the situation > more complicated if stable-backports was also affected by these > dependencies? If yes, then a temporary revert is likely the safest option. Let me first state that I agree with the question. :) This reply does not represent the committee as a whole and merely transmits my own views on the matter. We reached this bug as the additional dependencies caused problems to the base system such as #1140305 (misc:Depends pulls systemd on chroots). Some of these problems were addressed in other packages, but those changes have not been backported to trixie. This makes their inclusion into backports generally risky (even though we do not expect the affected packages to be rebuilt with a debhelper backport). The order of dependencies (and whether systemd should be first) is also subject to debate. I see a non-zero chance of having it changed (but I also don't see us necessarily changing it). If we end up recommending stronger properties (see my reply https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141909#97) such as systemd-tmpfiles functionality becoming essential, the dependency could possibly be removed longer term. My expectation is twofold here. The choices up for discussion very much influence those two commits. Many outcomes require changes here. The other expectation is that we do not want the current state, because that's what brought the matter to the committee. I do not expect debhelper in stable forky to retain these as is. When changing debhelper, we can update most affected packages via binNMUs and some via NMUs in unstable and once all of it has transitioned to forky, we may pretend the intermediate state never happened. If we were to add these commits to trixie-backports, we may have to consider the intermediate state in more transitional reasoning. As with any prediction of the future, I may be wrong. Therefore, my preference is to not include those commits in trixie-backports. Regarding the end state and given that time has passed, my current view (subject to change with ongoing discussion) is that systemd-tmpfiles should not be essential (neither transitive nor direct). We should also avoid pulling systemd into chroots, so putting systemd-standalone-tmpfiles first seems most plausible to me even though systemd is the default. Additionally, I see us making systemd more reliable during upgrades (what Michael proposed). Does that help or would you prefer something more official? Would you be willing to wait until Friday? Helmut
