Re: merged-/usr transition: debconf or not?
Simon Richter <sjr@debian.org> writes:
> I think the main blocker at the moment is that the dpkg change *also*
> has the potential to break a lot of things if it isn't carefully
> designed.
I think you can simplify that problem space considerably because we know
exactly what symlinks we care about and we don't intend to support going
backwards (in other words, once you have merged /usr, it's not supported
to turn /bin, etc., back into regular directories again).
Therefore, dpkg can be configured with the list of the symlinks that
*must* exist for it to be willing to operate on the system. Once it has
been put into merged-/usr mode (which includes updating its state database
to reflect the new canonical paths of all installed files), if those
symlinks do not exist or do not have the correct targets, the system state
is not safe and dpkg can (and probably should) abort and refuse to operate
on that system.
That modifies the problem of systems in various weird configurations from
"weird things may happen" to "dpkg will (safely) refuse to run" and we can
provide a tool to fix such a system by creating the correct symlinks.
(This tool may well just be the existing usrmerge tool.) Getting into
that state will be hopefully rare if we structure the upgrade process so
that first one converts the system to merged-/usr if this has not already
been done, then upgrades dpkg, then tells dpkg to switch into merged-/usr
mode, and then safely upgrades the remaining packages.
> From dpkg's perspective, we now (kind of) change the policy for
> directory-vs-symlink conflicts, which dpkg currently resolves in favour
> of the directory.
I don't think we should be doing anything of the sort. I think we should
introduce a new concept specifically for this case and have the remappings
of files for merged-/usr, once dpkg is in merged-/usr mode, take
precedence over any rules like that. We do not want dpkg to be applying
some policy or heuristic about directory vs. symlink conflicts for
symlinks related to merged-/usr. We know exactly what we want the rule
and behavior to be. That sort of remapping should happen way before any
other dpkg analysis of the package or system state.
In other words, I argue that once dpkg is in merged-/usr mode, it should
treat a package with files in /bin exactly as if the files were in
/usr/bin, at an earlier stage than when it starts looking at the file
system.
We're not trying to create a generalized feature here. Merged-/usr has a
very specific definition, with very specific and clear behavior that we
need from the package manager. Trying to generalize this is going to make
a mess and make it much harder to reason about the behavior or test it.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: