Re: merged-/usr transition: debconf or not?
Hi,
On Fri, Nov 19, 2021 at 12:28:56PM -0700, Sam Hartman wrote:
> But we could you know fix dpkg:-)
> I'm sure that will be painful at the political level, but personally I
> think it needs doing.
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.
The problem space right now is huge:
- for upgraded systems, the system could be pre-usrmerge, or the
conversion could have been performed by any usrmerge version that
ever existed (and the usrmerge package could have been deinstalled
and reinstalled since, so the patches to the conffiles it performs
could be inconsistently applied).
- for upgraded systems, any version of usrmerge since the last stable
release could be installed
- for upgraded systems, unless the usrmerge package is discontinued,
it could be upgraded at any point during the update.
- for freshly installed systems, dpkg is first invoked on a
non-usrmerged tree, and should convert the installation as soon as it
becomes aware that conversion is desired (which might not be
something we want to hardcode in dpkg, but possibly configure from a
separate, Debian-specific package like base-files).
- for freshly installed systems, initial unpack might be controlled by
debootstrap from stable, which is usrmerge aware, so some of its
workarounds may be active, and we need to properly capture this
state, too.
- freshly installed systems might be created with cdebootstrap or
multistrap, and could be generated in --foreign mode
- the dynamic loader is specified to be on the root filesystem, and that
is part of the ABI standard and not under our control, so we cannot get
a conflict-free dpkg database in bookworm.
>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. That was done in ancient times because it was somewhat
easy to do this in a package by accident. Not sure if that still
applies, but if it does, then we need to formulate the new policy so
that we don't catch a regression here (which is why my original idea to
just ship the symlinks in base-files is a bad idea).
>From the way dpkg and the Debian Policy are initially designed, it is
obvious to me that they started out as specification documents, and only
when these were hammered out, they were poured into code and rules, and
we've been operating from that stable base since, with two exceptions
where technical facts were created without updating Policy accordingly,
and which has both times been controversial.
My interpretation of the "political" situation is that we need this to be a
group effort, because no single person has the necessary time to do a
thorough enough job that they would feel comfortable signing off on it. I'd
be reluctant to do so even if I had three months of uninterrupted time --
that's the level of complexity I see here, and I suspect Guillem feels the
same.
So I believe the way forward will be writing a specification and giving it
enough eyeballs to identify problem cases. Finding the adversarial example
for the status quo was easy, since I had to find just one -- the goal now
is to get to a state where we don't find such an example easily anymore.
The specification should explain how the transition can be finished with
the bookworm release for all the different ways packages can be installed,
and it should describe the necessary code changes and new test cases to get
full coverage, and the document should be signed off by multiple people who
jointly take responsibility, to avoid placing all of that on a single
person -- because that's what's impeding progress right now, that no one
wants to be that person or even feels able to.
The description of the problem space I put above is likely incomplete and
overzealous at the same time (for example, I haven't checked how different
the previous usrmerge packages are, and which of them ever made it into a
stable release), so this is also just a starting point. I'll happily spend
time refining this or any other proposal, but I'm too time-constrained to
be the main driving force here -- this is not my day job, after all.
Simon
Reply to: