Hi Ian,
On Sun, Dec 24, 2023 at 10:39:43PM +0000, Ian Jackson wrote:
> Chris Hofstaedtler writes ("Bug#1059417: ed: install (r)ed into /usr/bin"):
> > I'm attaching a trivial patch to implement such a move.
> > As explained in debian/changelog, the update-alternatives calls are
> > intentionally kept unchanged, to preserve existing user
> > configuration.
>
> I assume that you are following a plan developed by Helmut et al, as
> part of the overall Debian usrmerge mitigation plan.
I confirm.
> I don't think I agree with this change, as provided, because it will
> cause ed to move to /usr/bin on downstreams that don't do usrmerge.
I don't think there is any reasonable way to continue supporting
unmerged layouts. There are many places already that break subtly there.
For instance, the protective diversions for m-a:same shared file loss
generally leave the old file around in the aliased location on umerged
systems. We do not have the resources to support both merged and
unmerged layouts. A main reason to switching to merged-only was reducing
the support cost down the line.
> And then, without changing the diversion, the package is actually
> broken.
Could it be that you mean s/diversion/alternatives/ here? I am having
difficulty locating said diversion and your argument becomes true when
interpreting it the other way.
> I think there could be an affordance in dh_auto_configure that allows
> this all to work properly.
>
> I assume there is some reason why we aren't, in Debian, changing
> dh_auto_configure to interpret --bindir=/bin as --bindir=/usr/bin.
I am all ears. I do not harm unmerged users intentionally. When there is
a cheap way to implement mitigations without hurting unmerged, I do so.
The change you propose here is not without issues.
For one thing dh_auto_configure has never inspected user's arguments so
far. The promise has always been appending them. What you propose is a
significant departure from those semantics.
If we were to change debhelper in such a way, packages would move their
files on a binNMU. Such moves tend to cause RC bugs. Cases such as ed
are (hopefully) simple. If this change were to be done to e.g. gzip
(which is diverted by zutils), we could end up with /bin/zgrep missing
after upgrade.
While the intention is to make this as easy as possible on the
maintainer side, every time we changed such a default location
(dh_installinit, dh_installudev, systemd.pc, udev.pc) we were faced with
a number of packages breaking and filed patches for them beforehand. A
similar approach could be used here in principle.
The approach that probably is the easiest to unmerged downstreams is
dh-sequence-movetousr / dh_movetousr. It's a noop in bookworm-backports
and downstreams can similarly disable it when doing rebuilds.
Helmut
