Hi,I've also started work on getting usrmerge back into a sensible state, current progress is at
https://salsa.debian.org/sjr/dpkg/-/tree/wip-canonical-paths
All of these commits obviously need to be rewritten a few times, but the
general idea should be clear:
- all paths that can be aliased should be added to the in-memory database under each alias name
- the alias name is set up by a special control file in a package - file conflicts are to be resolved normallyI'd like to avoid a separate tool like dpkg-divert, because we need to be able to set up aliases without being able to run maintainer scripts, so these are useful from (c)debootstrap when setting up a foreign architecture.
Ideally we'd be able to get rid of any special usrmerge handling in other tools that way as well, and gain some infrastructure that will also be useful for declarative diversions.
The obvious interface breakage would be dpkg-query, which would probably behave like
$ dpkg-query -S /usr/bin/ls
coreutils: /bin/ls
but we have all the relevant file names handy at this point so we can
have a different format as well.
Transition would be a dpkg version that conflicts with usrmerge, and a systemd package that declares the alias and pre-depends on a recent enough version of dpkg, that will work for both upgrades and new installations.
If dpkg external to the new installation is used, the files will be moved during unpacking when the systemd package is encountered, if the files are first manually unpacked, and then overwritten later during a second round, that should still work (but we need to be aware of this case).
The most annoying part will be identifying all the corner cases, like crossgrades from ppc32 to ppc64, or from Debian to Devuan and back, and writing test cases for those.
Simon
Attachment:
OpenPGP_0xEBF67A846AABE354.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature