Russ Allbery writes:
> Ansgar Burchardt <ans...@debian.org> writes:
>> Moving files around in such a matter that they are still available in
>> the old location (via a symlink) is not a very invasive change, so there
>> is only a small risk of problems.
>
> I think it's fair to note that our past experience in Debian doesn't
> really support this. I've run into multiple problems in unstable with
> uninstallable packages due to various bugs in this sort of change, most
> recently with iptables. We repeatedly get the details of this change
> wrong in various subtle ways that create issues in some upgrade paths and
> not others.
Well, the iptables case is different: those are compat symlinks created
by the package's maintainer scripts, not the /bin -> /usr/bin symlinks
that merged-/usr sets up.
If we want to support packages such as iptables moving binaries from
/{s,}bin to /usr/{s,}bin while setting up compat symlinks on
non-merged-/usr systems, it might be useful to have a dh-usrmerge
package creating the maintainer scripts. (Also for some files below
/lib, but most libraries could just be moved without compat symlinks.)
This should be similar to what OpenSUSE has done; see the section around
`#UsrMerge` on https://en.opensuse.org/openSUSE:Usr_merge
This could also be seen as a slower path to merged-/usr: programs such
as `sed` would be in both /bin and /usr/bin and hard-coding either would
be fine (as with merged-/usr, but not without). Less static files would
be on a read-write root file system (if /usr is a separate read-only
fs).
In case a later Debian release would merged-/usr mandatory, the
conversion process would be less problematic as no files would be left
to move (just replace individual symlinks with a directory symlink).
Ansgar
