Re: merged-/usr transition: debconf or not?
Gabor Gombas <gombasg@digikabel.hu> writes:
> If you replace "rewrite /lib64 to /usr/lib64" with "rewrite /lib64/* to
> /usr/lib64/*", then this can easily be avoided.
True, although I think you still want to ensure that dpkg never messes
with those links. I don't think you want base-files to be able to drop
one of those links from the package and cause it to be removed by dpkg,
for instance.
Maybe I'm borrowing trouble for a scenario that won't happen (and I think
dpkg may have some special-casing of symlinks to directories anyway).
> 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.
All that I mean by special-case is that I think it would be a mistake to
try to shoehorn support for merged-/usr into some pre-existing dpkg
concept. The merged-/usr links are special relative to other files that
dpkg is managing and need to be treated with special care. We should add
a new concept to dpkg for these sorts of links.
I agree with making the exact set of links configurable. This also allows
handling the architecture-specific links in a clean way.
> 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.
I don't think we want base-files to take over the logic of usrmerge.
usrmerge is both complex (in part because it relies on Perl) and not 100%
hardened against weird issues, being interrupted in the middle of running,
etc. That's all fine for what it's doing as a one-time migration tool
that's run with care during an upgrade when the administrator already
knows Big Things are happening to the system. Putting the logic into
base-files makes it more of a routine thing and I think it should be a lot
more hardened if we do that (and I don't think that's a good use of
anyone's time). We ideally want usrmerge to be a tool each system runs
once, under controlled circumstances, and then never again (and isn't
needed at all for bootstrapping).
We have a migration strategy that's working. Let's stick with that
migration strategy without messing with it and instead just add a dpkg
database conversion step to the end of that migration.
I do agree that something needs to handle installing the configuration
file and laid out some options for that in another message.
> 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.
This is a very good idea. I was starting to think along those lines, but
hadn't taken it quite far enough. 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).
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: