Control: forwarded -1 https://salsa.debian.org/debian/debhelper/-/merge_requests/108 Control: tags -1 + patch
On Sun, Aug 20, 2023 at 11:19:56PM +0200, Michael Biebl wrote: > Related to that: > dh_installsystemd (and the old, deprecated dh_systemd_enable) currently only > consider systemd unit files that are installed to lib/ Thank you Michael and Niels (who privately pointed at the same thing). This is the kind of review that I was hoping for. > One could trick dh_installsystemd by running dh_usrmerge after > dh_installsystemd, but this approach obviously doesn't work, if you change > your package to build with --prefix=/usr, so the files are already in the > canonical location when dh_installsystemd runs. > > So this would need a corresponding change in dh_installsystemd. I guess for > the time being, it would make sense if the tool looked in both paths, at > least as long as the transition is ongoing. You are spot-on. Even before we released bookworm, we had a group of people (including Sebastian Ramacher and myself) advocating for doing this change. As far as I understand the discussion, the main argument against it was that it could encourage people to violate the moratorium. In reality, our refusal to fix this earlier did cause "reverse violations" of the moratorium where files previously shiped below /usr/lib in bullseye would be moved to /lib in bookworm. That happened to boinc-client, cfengine3, nvme-cli, podman, and powerman (see https://subdivi.de/~helmut/dumat.yaml). So I argue that the reasoning was wrong even back then. Keep in mind that Niels clarified that he wasn't really objecting the change, but didn't want to handle its fallout if any. Speaking of fallout, we now have DEP17 and dumat which allow as to quantitaively estimate what may break. * P1 is the main category we see here. This problem arises if we restructure packages and move files between / and /usr. Since we are rather early in the release cycle, not much restructuring has happened yet and all of the restructuring that would cause P1-style file loss, happened for bullseye->bookworm with nothing yet for bookworm->trixie (as of this writing). And since dumat.yaml is updated four times a day, we learn about such problems quickly. * P2 is a problem, but I've files patches for all in-archive instances already. No key packages are affected, so we can upgrade those bugs to RC-severity when problems arise. * P3 has had one instance that Luca Boccassi removed before bookworm, so for systemd units, no P3 problems are left in trixie and beyond. * P4/P5/P6/P7/P8/P9/P10 do not apply. If we were to lift the moratorium just for systemd units right now, we're likely to run into P1 problems due to later package restructuring, but there is little else that may go wrong. Due to these P1 problems, we still have the moratorium and I have repeatedly argued for an opt-in approach to moving files from / to /usr. Let me also put this into numbers. Across all suites, we have around 2200 binary packages shipping files in aliased locations. If you disregard systemd units, we're left with 1030 packages. In other words, more than half of the binary packages shipping files in aliased locations do so only via systemd units. I recognize that various people have repeatedly asked me to consider an opt-out approach and to look at these numbers. Thanks for your persistence. Does that also convince others to treat systemd units separate from the rest? It seems plausible to move systemd units in an opt-out fashion while moving other files in an opt-in fashion. The main benefit here is that we could use binNMUs to canonicalizes 1/3 of the archive. (This is less than half, because a number of packages shipping systemd units are Arch:all.) To me, the risks and cost savings for forcefully moving systemd units bear a trade-off that is worth considering (despite me earlier having argued otherwise). Unfortunately, evaluating risk is a subjective process to some extent and I know that we have quite some disagreement on how severe these risks are. How can we move forward here? In this instance, I welcome +1 and -1 style responses and you may send them directly to me if you want to save the list from such traffic. In any case, I implemented the changes to debhelper to recognize units in /usr. The change does not yet move units to /usr (as that is still prohibited by the moratorium and I don't think we have consensus on that aspect just yet). I am willing to handle the fallout of this change and have implemented the dumat service to quickly diagnose such fallout. Nevertheless, I welcome reviews of the debhelper MR referenced above. Niels already replied to the MR. He'll not interact (review/merge/upload) with the MR and authorized me to do those things (provided I handle possible fallout). Thank you. Helmut
