On Sat, 20 Nov 2021 at 14:54:30 -0800, Russ Allbery wrote: > That would make it akin to dpkg > --add-architecture, which feels like a good model (although as you mention > I don't think we want --remove-architecture).
Instead of dpkg --add-architecture, which is a top-level "verb" like dpkg --remove or dpkg --install [1], probably a better thing to resemble would be the options that already exist to change dpkg's behaviour, and in particular --path-exclude and --path-include? Options to make path A an alias for path B would be a lot like --path-exclude in that they really only make sense in a configuration file in /etc/dpkg/dpkg.cfg.d, although for symmetry they would presumably also have to exist as command-line options just like --path-exclude does. Here's a possible design (not fully thought out, and maybe wrong or unimplementable): --path-alias ALIAS=TARGET When unpacking or querying packages, paths below ALIAS will be transformed into the corresponding path below CANONICALIZED, where CANONICALIZED is the result of resolving TARGET relative to the directory containing ALIAS. This transformation is done before checking for file conflicts. ALIAS must be an absolute path. If the file list of any unpacked package contains a directory at ALIAS and/or CANONICALIZED, then ALIAS will be created as a symbolic link to TARGET, with its target directory created at CANONICALIZED. It is an error to have multiple --path-alias directives for the same ALIAS with different TARGET paths. This option should usually be set via /etc/dpkg/dpkg.cfg.d rather than as a command-line option. For example, a series of directives like path-alias=/bin=usr/bin can be used to implement the "/usr merge", causing /bin/bash to be unpacked as /usr/bin/bash while creating a symbolic link /bin -> usr/bin. With that, I believe a full implementation of merged-usr for all known architectures would be to install something like this, perhaps via base-files: # in /etc/dpkg/dpkg.cfg.d/merged-usr path-alias=/bin=usr/bin path-alias=/lib32=usr/lib32 path-alias=/lib64=usr/lib64 path-alias=/lib=usr/lib path-alias=/libo32=usr/libo32 path-alias=/libx32=usr/libx32 path-alias=/sbin=usr/sbin Rationale for TARGET being allowed to be relative: I believe the compat symlinks in merged-/usr are preferred in the form /bin -> usr/bin, to make sysroots (containers, chroots, btrfs root filesystem snapshots, etc.) easier to manipulate from outside. Rationale for ALIAS only being created if ALIAS and/or CANONICALIZED really exist in a package: we would probably prefer the multilib directories to be created "lazily", rather than having a /libo32 on systems that will never install a mips* package and a /libx32 on systems that will never install an x32 package. This is slightly nicer than the current implementation in convert-usrmerge and debootstrap, which creates those directories "eagerly" whenever the appropriate architectures are configured as either primary or foreign architectures. smcv [1] if dpkg had been designed with more recent CLI conventions in mind, I expect these "verbs" might have been subcommands like "dpkg remove", etc. as seen in apt/git/flatpak, which makes it a bit more obvious that only one is allowed