Gabor Gombas <gomb...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
