Michael Biebl:
Package: debhelper Version: 14.2 Severity: normal File: /usr/bin/dh_movetousr X-Debbugs-Cc: [email protected]Hi, to help with the usrmove effort, Helmut wrote dh_movetousr. This helper was meant as temporary measure, especially to simplify backports.
Hi, Thanks for handling that. :)
Going forward, I think we should remove this addon again from debhelper and packages should install files directly into non-aliased locations. For that, I filed corresponding bug reports [1]. In addition, I think it would be useful, if dh_movetousr became a noop with compat 15 (or rather, error out) and maybe also output a warning for compat < 15, saying that this addon is deprecated and scheduled to be removed. Before actually removing the addon, the list of rdeps [1] needs to shrink significantly I think and we'd also have to keep backports of debhelper in mind. There is no real hurry that but I would like to see this cleaned up eventually. Helmut, Niels, wdyt? If you agree, I could submit a corresponding MR. Regards, Michael [1] https://udd.debian.org/cgi-bin/[email protected]&tag=dh-movetousr-removal
I agree with the principle of cleaning up and removing this code. I am less sure that compat level does anything of value here though. The timeline for a compat level to clean up anything is measured in decade(s). And I mean that literally.
Take `dh_systemd_*`, which where replaced by `dh_installsystemd` in compat 11. Compat 11 was released in the end of 2017 (~8½ years ago) and compat 10 (the one before it) is not even deprecated yet. Add 2 releases for the removal on top of that, and we are looking at least 13 years between compat til new baseline.
Secondly, and equally important for me, it adds documentation and checklist items for every package to read and handle. We have 28 packages affected, but we impose a "if this package is one of the 28 packages that might still be using X, please deal with it" on 30k+ source packages. It does not seem like a good trade off of maintainer time to add a checklist that affects less than 0.1% of all source packages, which we have list of all affected source packages.
Thirdly, odds are given the low number of affected packages, this will likely be fixed before that compat level is even released and at least long before that compat level is deprecated. Which means it becomes a "retroactively removed change" for that compat level, which is generally a sign that it should not have been a compat level guarded change in the first place.
With that in mind, I am personally in favor of churning through the list of affected packages and then throwing out the code once they have been fixed. A compat level change seems too cumbersome and long winded for me given my understanding of the scope. At least from my current PoV, it seems like a much more lightweight, faster, and better approach.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
