Re: merged-/usr transition: debconf or not?
Simon Richter <sjr@debian.org> writes:
> 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.
Well, bootstrapping a new Debian system involves running a tool that
bootstraps a new Debian system. I think you're constraining the problem
too much.
It's a nice property that everything on the system comes straight from a
Debian package, but it's not a strict requirement, nor is it currently
generally the case (maintainer scripts do things, for instance). Those
symlinks are very special from a dpkg perspective; dpkg needs to refuse to
mess with them even when upgrading a package that provides them, which
would mean some irritating special-casing I suspect. It's not clear to me
that shipping them as tar members of a package is the right way to go, as
opposed to creating them separately as part of early system configuration.
> Dpkg has an elaborate per-file tracking to recover from errors, and this
> change introduces several new states and transitions,
Why? I am not convinced this is true, apart from the obviously-needed
one-time conversion of the state database.
It involves a new filter, applied whenever a package is installed, that
changes all the paths in the package to their merged-/usr paths, something
that seems like it should be done before any other package processing.
Once that's done, why would any new states or transitions be required?
You could convince me that writing the filter is complicated because there
may not be one place in dpkg where you can currently put such path
rewriting since dpkg probably wasn't designed with that operation in mind.
But it's going to be harder to convince me that there are new states or
transitions; that smells like an over-complicated design.
> That is the goal, yes, but this is a massive undertaking.
I'm still not convinced of this.
> 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.
This already sounds conceptually more complicated than just solving the
problem properly, with the caveat as mentioned above that writing the
necessary filter may be difficult.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: