Hi Helmut, On 22.04.23 10:44, Helmut Grohne wrote:
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.
Your argument of the dynamic linker being too special is interesting. I certainly agree that we must take great care at moving it, but on the flip side I do not consider the transition complete until we reach the point where we have moved it.
I think that if dpkg gains a useful level of support for aliases, it will no longer matter which path is used in the libc package, and I'd consider the transition complete then because it no longer requires any kind of coordination.
Do you actually see us coping with some aliases (e.g. the /lib one) eternally?
I think that dpkg will need to support them eternally, so package maintainers don't have to.
That's why I went with "this needs to be a separate mechanism."
Or do you want to say that we need a new mechanism to be able to move such important files?
I meant a new mechanism to make sure creation of aliases is not accidentally triggered because of the difference between
mkdir -p $(DESTDIR)foo
ln -s ../bar $(DESTDIR)foo
and
mkdir -p foo
ln -s ../bar $(DESTDIR)foo
which is a totally understandable mistake to make in an install script.
I did not have this goal in mind, but now that you mention it, it seems important to me. It is not clear to me though how that control file actually gets us there. In your picture, which component is in charge of actually creating the symbolic links on the filesystem? Can you go into detail as to how you imagine that bootstrap without special-casing?
The symlink would still need to be in data.tar, but the control file is responsible to get the symlink also registered as "this is intentionally meant as an alias."
The reason it needs to be in data.tar is the two-stage installation used for (c)debootstrap --foreign, where we stop after the unpack stage, and replace init by a shell script that runs dpkg to actually install the packages. This works even when the host cannot execute the target architecture -- just the first boot takes a little longer.
The appropriate requirement in Policy would be that Essential packages need to be functional after unpack only, when no maintainer scripts have been run, so if ld.so is in /usr/lib, then /lib -> usr/lib needs to be a symlink in a data.tar, and if /ld.so is in /lib, then /lib needs to be a directory, so some coordination is needed there for the installer to remain working.
The advantage is that it works for Essential packages, like the one shipping /lib/ld-linux.so.2.
In the --add-alias variant, I think we would still move the dynamic linker to /usr and ship the /lib symlink in base-files eventually. I admit that it is not entirely clear how such a move could be performed safely, but that seems like a solvable problem to me. In that way, I fail to see the control file being an advantage.
When the alias is registered, we need to look at the existing state, because we might be inside a new installation (which has exactly what is in data.tar), an upgrade of a merged installation, or an upgrade of an unmerged or partially merged installation, and we want to get into a consistent state as quickly as possible and continue from there.
I think the appropriate time would be preinst/postrm, or close to that. Having a control file would mainly give us a declarative interface that always works at the right time (and TBH I'd like to move diversions and alternatives to a declarative interface at some point as well, so we can have archive-wide static analysis, and fewer maintainer scripts overall, which should give a nice speed boost, but that's not part of the usrmerge thing).
Simon
OpenPGP_signature
Description: OpenPGP digital signature
