Re: DEP 17: Improve support for directory aliasing in dpkg
On Sat, 22 Apr 2023 at 12:43:09 +0200, Helmut Grohne wrote:
> Guillem also
> raised that this is changing the source of truth from the dpkg database
> to the actual filesystem, which Guillem considers wrong and I find that
> vaguely agreeable.
To be fair, dpkg does already have at least one case where it treats
the filesystem as the source of truth, namely a local sysadmin (or
even a package, I think?) substituting a symlink-to-directory for a
"real" directory. It has supported this for a long time, and requires
specific action to avoid that behaviour (usually the dir-to-symlink and
symlink-to-dir maintscript actions). The strategy used in the usrmerge
package wouldn't have worked otherwise.
I believe the original use-case for this was offloading large
subtrees to a secondary filesystem, like a symlink
/usr/share/games -> /srv/large-secondary-disk/games (which is better
achieved with bind-mounts, or perhaps btrfs subvolumes if you use btrfs,
on modern systems).
If I understand correctly, this feature is considered vaguely deprecated,
but is also quite entrenched, to the extent that we even have wording in
Policy specifically to make it work better, namely the rule about symlinks
within a top-level directory (/usr/lib/foo/data -> ../../share/foo/data)
being relative, while symlinks between separate top-level directories
(/usr/bin/foo -> /etc/alternatives/foo -> /usr/bin/foo-full) are absolute.
The key difference in how usrmerge uses this dpkg feature is that
traditionally the target directory would be somewhere non-dpkg-managed
(meaning that the resulting path aliasing doesn't affect dpkg's
behaviour), whereas in usrmerge, both the symlink and the target directory
are in the subset of the filesystem tree that is managed by dpkg (meaning
that the resulting path aliasing becomes significant).
smcv
Reply to: