Re: /usr-merge status update + next steps
On Tue, 22 Aug 2023 at 10:21, Helmut Grohne <helmut@subdivi.de> wrote:
> 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.
Thanks for this - not only I agree that immediately converting all
packages shipping units is a good idea and a great starting point, but
I think (after doing that first bit separately if it's easier to make
progress that way) we should go much further, and opt-out-update
everything. I do not see any valid reason why any package should be
allowed to ship files in the legacy directories once we have a
strategy and a tool in place, besides some temporary workaround that
may or may not be needed on a package-by-package case due to
unforeseen circumstances - in such cases, allowing an opt-out while
things are worked out (together with an RC bug to track it) would be
fine of course. But to me the most important thing is that the message
needs to be: we now have a strategy to approach this, hence everything
either gets converted or removed from testing, period. The opt-out to
follow your strategy for the pseudo-essential set of course can be
treated differently as required.
TL;DR: dh_usrmerge should allow an opt-out but default to convert,
without any new flag/compat level change required, and anything not
using debhelper should get an RC bug at the same time to perform
whatever manual step is needed to achieve the equivalent output.
Reply to: