Re: merged-/usr transition: debconf or not?
Hi,
On Sat, Nov 20, 2021 at 09:22:27AM -0800, Russ Allbery wrote:
> The drawback here is that dpkg is going to rewrite all paths like /lib64
> to /usr/lib64, which would naively *also* apply to the base-files
> package when it looks at that package, but that can't be allowed because
> now we're back to the situation where dpkg's state database is
> inconsistent with the file system and dpkg thinks that base-files
> contains some nonsensical /usr/lib64 to /usr/lib64 symlink.
If you replace "rewrite /lib64 to /usr/lib64" with "rewrite /lib64/* to
/usr/lib64/*", then this can easily be avoided.
> I think in this approach there would need to be some special-case code
> directly in dpkg that recognizes the usrmerge symlinks [...]
Talking about "special casing" in dpkg is bothering me for a while. And
there is a relatively simple way to avoid any kind of special casing:
move the information out to a configuration file (which would _not_ be a
conffile) - and now the code has no special casing, just
configuration-driven logic.
This new configuration file could be shipped by base-files itself, to
ensure it does not get out of sync with the filesystem structure shipped
in base-files. Then base-files' postinst would more or less need to
include the current usrmerge package, plus whatever is needed to convert
dpkg's database.
This new configuration file would not be consumed by dpkg directly when
installing packages, but only when the database conversion is called,
and dpkg would keep an internal list of the rewriting rules which are
active. Doing so would allow enforcing rewriting rules can only be added
but never removed, which would avoid potential issues if base-files gets
downgraded.
Gabor
Reply to: