Re: merged-/usr transition: debconf or not?
Richard Laager <rlaager@debian.org> writes:
> Is this particularly hard to fix, though?
> Can't we just do something like the following pseudo-code:
[...]
> (I've used /bin -> /usr/bin as an example, but the canonicalization must
> deal with the other merged paths too.)
> The second bit ensures that all new operations write canonicalized paths
> (e.g. /usr/bin/foo) into the database regardless of whether the .deb
> shipped with /bin/foo or /usr/bin/foo. This ensures the database stays in
> sync with the filesystem moving forward.
> The first bit performs a one-time canonicalization of paths in the
> existing database. An on-disk flag ensures that this is run only once
> (for performance reasons only, because it's already idempotent). This
> corrects the existing database-filesystem mismatch.
> The one-time canonicalization can be removed once non-usrmerged systems
> are no longer supported. The second bit needs to live (probably a lot)
> longer, until it's no longer reasonable to install a .deb containing
> non-usrmerged paths (which might be old or from a third party).
> Am I missing something here?
I also don't understand why this isn't the correct solution. It seems
obvious to me that we should simply teach dpkg about path aliases and have
it update both its internal state and its processing of new packages to
canonicalize paths so that it has an accurate representation of the world,
and then ensure dpkg is upgraded first.
Are we missing something? If not, what is blocking this solution? Is it
simply a matter of someone digging into dpkg's code sufficiently to put
these changes in the correct location? Or is there some other issue?
It seems like a huge waste of resources to me to do archive-wide package
inspection to try to find patterns that might cause problems, and to ask
all maintainers to remember this rather obscure rule, when we could just
fix dpkg to make the problem go away.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: