[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

Russ Allbery writes:
> Ansgar Burchardt <ansgar@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

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).


Reply to: