control: retitle 926699 libc6 foreign/biarch: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}
control: affects 926699 libc6
Hi,
I have been asked privately to work constructively on a solution,
otherwise my bad behaviour will likely lead to a decision that I will
regret if this discussion leads towards an appeal to the TC.
So let me explain in details my position on the subject.
The issue
---------
First of all let's describe the problem.
usrmerge works by moving all data from /lib into /usr/lib and then
creating a symlink /lib -> /usr/lib. The same is done for the biarch
or triarch directories, namely /lib32, /lib64, /libx32 and /libo32
depending on the architecture. Note that this part is done by usrmerge,
but doesn't appear in its description, nor in the debconf question
asked to the user. It is important to note that it is done directly on
the filesystem and that this change is not known to dpkg.
When a user install for example libc6-i386 on an amd64 system, dpkg will
follow the symlink and will install everything that should go on /lib32
into /usr/lib32 as expected. This works as expected. However when the
package is removed, /lib32 will be removed. In turn when it is installed
again, the symlink /lib32 -> /usr/lib32 has disappeared.
This is the consequence of:
1) the dpkg policy to remove the last used directory or symlink on
package removal.
2) libc6-i386 being the last package using /lib32.
There is nothing special done with that regard in the glibc maintainer
scripts.
Similarly, that issue also affects the libc6 package when used as a
foreign architecture. For example installing libc6:amd64 on an i386
system and then deinstalling and reinstalling it will cause the /lib64
-> /usr/lib64 to disappear. I guess there might also be some more
issues when installing biarch packages as foreign packages.
The solution envisaged by the usrmerge team
-------------------------------------------
The usrmerge people considers that it has to be fixed in the glibc
maintainer scripts. As explained above, it would mean that the preinst
script is responsible, if usrmerge is activated, to create the
/lib{32,64,o32,x32} -> /usr/lib{32,64,o32,x32} symlink if it doesn't
exist. The directory might not be empty as a result of a partial
conversion to usrmerge (yes those system will exists). In turn this
directory might be the one of the dynamic linker used for executing
the maintainer scripts (dash/bash, coreutils). So this means the
maintainer scripts have to handle the case of moving the dynamic
linker without breaking the system.
In short it means *the most tricky part of usrmerge has to be
implemented and maintained in the glibc preinst scripts*. This is even
more difficult as the preinst script will be executed all the time and
not when the user ask for that. It won't ask the user for its permission
before. It doesn't have the option to abort if something looks wrong as
this will lead to a system difficultly recoverable for many users if
they are dist-upgrading their system to a new release (usually apt-get
install -f is not enough).
On the glibc side experience we have very bad experience of moving the
dynamic linker from one directory to another in the maintainer scripts,
and this has resulted in many broken systems. There are still even a few
bugs opened about that for which we haven't really understood the
problem. Looking at the usrmerge's archived bugs, it seems it wasn't an
easy road on the usrmerge side either.
Alternative solutions
---------------------
I do not understand why I should be the one responsible of finding a
solution to this issue. Anyway let me provide a few alternatives
solutions.
In my opinion, the root of the problem is that the symlink is created
without dpkg being aware of that. Therefore it removes it once there are
no users for it. This is exactly why for example base-files ships
/usr/src and we do not require all packages that ship a file in /usr/src
to have postrm script to make sure the directory still exists after the
package removal.
Therefore I really believe the best solution for this issue is to
make dpkg aware of the symlink, which means creating a package
containing this symlinks. This could be for example:
- in base-files, for example by depending on base-files-usrmerge |
base-files-nousrmerge
- in usrmerge after reconsidering that the package can be uninstalled
after the conversion.
- directly in the libc6 and libc6-xxx packages if the TC reconsiders the
"weak" situation for at least the /lib{32,64,o32,x32} directories.
Another alternative solution is simply to only consider /lib and
/usr/lib for usrmerge (like it is alreayd done in the user visible
interface) and ignore the /lib{32,64,o32,x32} directories, at least
until the state stays as "weak".
I would be happy if you could also work on your side to provide
alternative solutions.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature