Re: merged-/usr transition: debconf or not?
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
Reply to: