>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes:
Niels> As I understand it, the issue does not depend on whether
Niels> "usrmerge" is run before or after installing the "/lib"
Niels> version of "foo". On that assumption, running "usrmerge" as
Niels> a part of the upgrade and "cleaning up" in bookworm+1 is
Niels> liable to exactly the same risk as before.
I don't think so.
My assumption is that we will eventually produce a dpkg that handles
this situation better.
I think that every time we move files from / to /usr inside a package
before that new dpkg is introduced,
we increase our risk.
So my hope is that debhelper and maintainers refrain from moving files
from / to /usr prior to being able to depend on an as yet unwritten
dpkg.
I think that if debhelper moves systemd units and later a maintainer
moves units between packages, we can run into trouble with today's
dpkg. So we could potentially run into trouble as soon as someone
installs such a package from testing onto a bullseye system.
If debhelper were to hold off until after a fixed dpkg exists and we can
guarantee it is available,
I think that we avoid the risk of files disappearing.
So, based on my understanding, I think the risk is worse today than it
would be if we rolled back the debhelper change.
Put another way.
You can choose any two of:
1) alias things outside of dpkg I.E. usrmerge moves files and creates
symlinks
2) Move files inside a package within the knowledge of dpkg
3) move files between packages.
If you choose all 3, files may disappear depending on upgrade ordering.
We've already chosen 1 with the buster debootstrap change.
We often choose 3 as part of regular package reorganization.
I think we should not choose 2.
It's possible I'm missing something .
If so, I'd appreciate help understanding what it is.
This strongly depends on:
> * Who volunteered to be the
> "we" that provide this plan?
> * When is "until" we have a
> defined plan?
So, I think that the discussions here have been converging on things
that would work.
I'm happy to volunteer to assist in trying to find what consensus there
is if that helps.
The discussion here has convinced me at least that actually
canonicalizing paths (making the path inside the package match reality)
is not a safe thing to do until dpkg is changed.
I do think we could force usrmerge (or something similar) to be
installed without changing dpkg.
The dpkg maintainer hasn't been happy with the discussions here, and I
think facilitating to a level where Guillem is part of the consensus is
beyond my skill.
So I don't actually know how to get to something actionable. I do
believe the chance of breakage if we move around paths inside packages
is high enough that we should block path canonicalization on a dpkg that
can handle that, even if that takes a long time.
Attachment:
signature.asc
Description: PGP signature