Hi, On 08.04.23 04:35, Guillem Jover wrote:
A little later, Simon Richter also looked into the problem (https://lists.debian.org/debian-dpkg/2022/12/msg00023.html), but remained silent after the initial post.
Yes, I am quite busy, but it's not forgotten. I keep adding new test cases.
* dpkg cannot safely and atomically perform such switches (and I don't see it ever being able to portably do so, so I don't see ever supporting that).
The dpkg core cannot, but the approach by the diversions mechanism can be replicated here: a dedicated tool that adds an alias, and performs the necessary filesystem change. Dpkg already stat()s the global diversions list after executing a maintainer script, for precisely this reason.
The difference to diversions is that cleanup after reload is more complex, but that only happens when the list of aliases changes, and that is pretty much not a hot path.
Maintaining all the aliased paths in the database is not expensive, we double the number of entries, but it's still a hashmap with 262144 buckets. The most annoying thing is that it finally breaks statistics as the number of nodes now no longer corresponds to the number of files.
* No packages ships those symlinks (and none should! as that would currently imply having the same pathname contain different file types on the same system, introducing ordering issues and file type conflicts).
Dpkg already has defined behaviour for directory vs symlink: the directory wins. In principle a future version of dpkg could change that, but /lib/ld-linux.so.2 is just too special, we'd never want to have a package that actually moves it.
That's why I went with "this needs to be a separate mechanism."The reason to use a control file instead of a tool would be to install the alias from an Essential package, so the old-school "unpack essential packages, then overwrite with dpkg" approach to system installation would work again without special-casing usrmerge in debootstrap&co.
* Wants to be a generic change but it is really targeted to this specific mess.
This mechanism could have made the transition easier, so it is a generally useful mechanism. Also, this could possibly be built so unregistering the aliases will effektively do an usrunmess.
* This information can get out of sync with reality, as it adds an additional and unconnected with anything source of truth, that dpkg cannot do anything about if it diverges (in contrast to diversions or statoverrides f.ex.). This can never happen when that information comes from the real source of truth (the fsys metadata via the .deb).
Yes, we need to go back to dpkg as source of truth, but pragmatically we need to pick up existing installations where they are, including those with incomplete usrmerge transformations (I have a few of those, because usrmerge got intermittently installed there).
Basically, until the alias is registered, we wouldn't be worse off than the status quo, and picking up the existing install is as simple as "if the symlink already exists when the alias is registered, we don't need to do anything."
* This also adds undue complexity, by supporting those as admin aliases. The admin generated redirecting symlinks are already annoying, I'd rather not add further to that pile. I don't really want to support admins doing this (dpkg-divert does not even support diverting a directory).
That's a policy decision. I think it's completely valid to have a mechanism that is only to be used by other packages (but that's also part of the reason why my proposal was to use a control file).
[ As an aside, I think ideally eventually nothing distro provided should
be allowed to be installed within an aliased dir, and dpkg should
eventually just error out in those cases, which eventually would get
rid of the aliasing problems and any such complexity (I'm not sure how
or when that would be feasible though, but obviously in Debian at
least not until nothing ships files there). ]
There'd be no sensible upgrade path though.
It was suggested that the mapping could be managed via a special control file `canonical`. Given that aliasing is not a common operation, the benefit of handling it declaratively is minor. Beyond that, aliasing can also happen as an customization issued by an administrator. Therefore, a command line based approach is preferred.
The advantage is that it works for Essential packages, like the one shipping /lib/ld-linux.so.2.
As long as the package does not provide the symlinks, shipping this type of information declaratively would also be conceptually wrong.
In principle, the package could also ship the symlinks. With current dpkg, the file conflict causes the symlinks to be ignored, and that makes sense for safety purposes (imagine a broken symlink in a package moving all installed files), so a mechanism that says "this symlink actually has precedence over a directory" is still required.
dpkg cannot guarantee atomicity and safety for this kind of aliasing switch, and I don't see it will ever be able to support performing such switch, as that can break the system.
I think we should be able to do a better job safety-wise than the existing usrmerge package -- check conflicts using the fsys database, create hard links for new names, rename the old directory to .dpkg-old, create symlink, then clean up.
Full atomicity isn't required, only that we don't require calling any external programs between moving ld.so and creating the /lib symlink, and being able to rollback any changes in that process if something fails in between.
I thought it would be clear that if there is stuff that depends on any of this kind of changes to dpkg, relying on those changes in Debian would not be possible until after trixie+1. Of course there is always the route to further pile up over the Jenga tower of hacks, by for example adding huge amounts of Pre-Depends…
Shipping the magic symlinks in base-files and adding a versioned Pre-Depends there should work in trixie already, for both new installs (that never had an older dpkg) and upgrades (which respects the Pre-Depends).
The usrmerge transition will not be finished until trixie+1, but most of that will be policy atavisms like "do not move files between / and /usr unless you can guarantee that the file will not be moved to another package in the same upgrade."
The most annoying thing in this process will be defining test cases. We can probably reduce the problem space by disallowing certain things (e.g. do we need to be able to move conffiles to aliased paths?), but I'm not sure it will be worth it.
A test case that I want to support is removal of aliases, in case the commercial sponsors behind the various changes shift their priorities.
Simon
OpenPGP_signature
Description: OpenPGP digital signature
