Hi, On 22.08.21 05:10, Theodore Ts'o wrote:
So with the goal of trying to enumerate possible solutions, it sounds some combination of:
(a) disallowing moving problematic files between packages, with possibly some
QA tools to enforce this
(b) keeping the next release cycle *short*, say only a year
(c) requiring that dpkg be upgraded first, and having dpkg and
related tools understand the concept of usrmerge and the
fact that /{bin,lib,sbin} and /usr/{bin,lib,sbin} are identical
for usrmerged systems
might be possible paths forward. Do you agree?
Yes. I'd even say that if we don't have any problematic moves, we can get away with updating dpkg at any point during the upgrade -- the current state is more "fragile" than "broken", which would help immensely because we don't have to expend manpower on updating autobuilders and explaining to people that dist-upgrade is not to be used.
> What are other possible solutions?Current dpkg already has handling code so that /bin/foo -> /usr/bin/foo is not a problematic move even on usrmerge'd systems, so a possible policy would be to allow those and disallow package splits, that way we could continue transitioning packages. If we manage to move all files out, the discrepancy between the dpkg database and the filesystem will be minimal (but we can't transition libc6 that way, because usrmerge left us with a state where we can't unpack a libc6 that provides ld.so as a symlink in /lib).
The approach that will take the least amount of work but is a nasty horrible hack would be to integrate usrmerge into dpkg, forcibly converting any system that isn't yet, updating the dpkg database in either case, and then filtering file lists during writing going forward.
I'd rather not try to make the conflict checking code itself understand aliasing through symlinks, that looks as if it would be a source of bugs, but transforming file lists to canonical paths before checking should be doable, and any symlink-vs-directory conflict outside those we explicitly handle then become fatal instead of silently ignored.
The most generic approach would be to have a symlink farming mode in dpkg, where it has a goal (as defined by a package) to create a symlink /lib -> usr/lib, but while another package declares /lib to be a directory, the directory has precedence and dpkg generates the minimal set of symlinks that create the same effect -- so if /usr/lib/foo exists and /lib/foo doesn't, it generates a symlink /lib/foo -> ../usr/lib/foo.
This would allow us to transition the package contents to match reality on usrmerged systems, and dpkg will finish the transition as the last package that declares /lib to be a directory is gone, and it could be used for any future transitions that need old paths to work for a while.
Without an extra hack, this would not allow us to transition ld.so out of /lib though because
/usr/lib/ld-linux.so.2
/lib -> usr/lib
would be unpacked without the symlink because the file conflict causes
the symlink to be dropped.
Simon
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature