Re: merged-/usr transition: debconf or not?
Hi,
> > (I've used /bin -> /usr/bin as an example, but the canonicalization must
> > deal with the other merged paths too.)
/lib and /lib64 are a bit special, because they are part of the ELF ABI,
and any manipulation of these paths needs to be atomic.
Bootstrapping a new Debian system works by unpacking Essential packages
with ar+tar, i.e. not using dpkg. These packages will always be unpacked
to the file names listed inside the packages.
So, new systems will either need a package that ships the /lib ->
usr/lib symlink in the Essential set, or we need to ship the dynamic
linker in /lib, which would be a conflict during unpacking.
> > 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.
This loses the information about the original path, so this would be a
trapdoor operation that can not be undone without affected packages
going into reinstallation-required state (and we probably couldn't even
identify those).
Ideally, I'd rather not hardcode the list of top-level symlinks into
dpkg, because they might be architecture-specific, or change over time,
so there should be a mechanism to add and remove transformations.
> > 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).
My expectation would be that this code will be here to stay, because it
will be required for bootstrap.
> 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?
If it were that simple, someone would have done that already. Dpkg has
an elaborate per-file tracking to recover from errors, and this change
introduces several new states and transitions, last but not least
because we also have filters and diversions as transformations on the
database -- but the usrmerge transformation is supposed to be orthogonal
to that.
> 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.
That is the goal, yes, but this is a massive undertaking. We already
have a quick hack for usrmerge support in dpkg, which is the check that
allows moving a file from /bin to /usr/bin within the same package
without the file being deleted in the end (because deletions are
processed last for obvious reasons), and the obscure rule is precisely
the limitation of this hack.
I've stumbled across this hack while investigating if it was possible to
"just" fix dpkg. :P
Simon
Reply to: