Re: merged /usr vs. symlink farms
Hi!
On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote:
> Afaict we have still no idea on how to move on.
>
> 1 I think you agree that there is a significant number of usrmerged Debian
> installations out there. It does not really matter whether there are 7% or
> 40%. They exist and should (keep) working.
By my definition, these have never been working correctly, but
semantics I guess. My wish would be to indeed salvage those systems,
that's why I implemented dpkg-fsys-usrunmess. But if people refuse,
then at some point I'd personally consider them lost, TBH. :/
> 2 As you have stated there are known issues with dpkg and usrmerged
> systems. Some of them are are triggered by moving files from / to /usr.
>
> Starting from here it is hard to see a way forward.
Well, in my mind the first and most immediate action that would be
done, is to stop the bleeding, by:
- reverting the changes in deboostrap in sid, bullseye (and ideally
in buster too),
- reverting the notion that split-/usr is unsupported (which includes
the extremely confusing interpretation about this applying to
sid/testing too), and update documentation such as release-notes,
etc.,
- adding a Conflicts against usrmerge somewhere (dpkg, base-files or
similar) for extra caution,
- (optionally) removing usrmerge from buster, bullseye and sid,
I'd be ready to prepare patches or file reports for any of these.
But then, my expectations regarding Debian have plummeted so…
> Is it a realistic option to require something like
> -----
> dpkg --purge usrmerge
> dpkg-fsys-usrunmess
> -----
> pre dist-upgrade to bookworm to get back all systems to a sane (from
> dpkg POV) state and start fresh?
If by requiring you mean documenting the requirement, then I don't
think that would be enough.
But I could see introducing a preinst somewhere (perhaps base-files,
to permit upgrading dpkg itself) which would check for those unsupported
systems and emit a big fat message explaining the situation and
instructions to follow to be able to proceed, then abort. Similar in vein
with how other preventions (AFAIR) have been implemented for example on
glibc or udev for environment, multi-arch or kernel requirements.
Sadly, even introducing that into bullseye would not guarantee that the
bookworm upgrade would already be in a sane state, as there's no
guarantee people do not skip point releases. But I assume it would cover
most of the installations. So the problem would be greatly minimized.
Only after the bookworm upgrade has been completed this would be
guaranteed.
> Is this robust (except for crash as stated in the manpage), or would
> you consider it beta-quality?
There's a known problematic interaction with a systemd's emergency mode
misbehavior/bug, which I've worked around, plus some other robustness
improvements I've prepared that will be included in 1.21.0, and targeted
for 1.20.10. I should probably also add a temporary policy-rc.d to
batch and defer all service actions for after the mass reconfiguration,
which I'll try to code up soonish to further improve robustness.
Otherwise I've taken great care and consideration on trying to make it
as robust as possible, but I guess out of cautiousness and given the
nature of what the script is doing (which is still a hack, although a
self-contained one at least), I'd be hard pressed to probably ever
declare it 100% safe. :/ Of course more testing is always helpful!
Thanks,
Guillem
Reply to: