On Aug 19, Aurelien Jarno <aurel...@aurel32.net> wrote: Thank you for expressing your position in more detail.
> 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. I do not think that describing this implementation detail would be generally useful to users, but you are right. This complexity is an effect of having to keep supporting non-merged systems, but I am not willing to fight that battle right now. > There is nothing special done with that regard in the glibc maintainer > scripts. Agreed. > The usrmerge people considers that it has to be fixed in the glibc > maintainer scripts. I am not dead set on this, but so far it seems to me that, as long as we need to keep supporting non-merged systems, such a solution would both solve all issues and be the simplest one to implement, as long as it is correctly defined in scope. > 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 An half-converted system is (more or less) broken and it is not libc's responsability to fix it. Pseudocode: # is this a merged-/usr system? if [ -L /lib ]; then # has the link already been created? if [ -L /lib32/ ]; then : # if it has not, is a directory already there? elif [ ! -d /lib32/ ]; then # if not, then create it ln -s /usr/lib32/ /lib32/ # is this needed or not? [ -d /usr/lib32/ ] || mkdir /usr/lib32/ fi fi Implementing this would cover all non-pathological cases and improve on the current situation. > 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. No, it would never attempt to move any file: either e.g. /lib32/ does not exist, and then libc6-* would create the link, or it does, and that system is half-converted but it's not libc's fault, and continuing to install some of the files in / would not break anything. > In short it means *the most tricky part of usrmerge has to be > implemented and maintained in the glibc preinst scripts*. This is even I disagree: only the most basic function would need to be implemented by the libc packages: creating a symlink if one is needed and it does not already exist. I would definitely never propose to move to other packages the migration support currently implemented in usrmerge. > 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). As explained, I think that this code can always be successful. > 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 I wonder what the base-files and deboostrap maintainers think about this, since it would require some changes in their packages (non-trivial ones in deboostrap, I think). This also has the downside that this way it would be impossible to delete the /libx32/ etc links when they are not needed, since they would be created every time the package is updated. > - in usrmerge after reconsidering that the package can be uninstalled > after the conversion. I am not sure that this could actually work: if the converter package is designed to be installed on a non-merged system to convert it, what would happen when it tried to install a /lib/ -> /usr/lib/ link in such a non-merged system, where /lib/ already is a directory? (It would also have all the downsides of the precedent point and moreover require installing three extra Perl modules on every Debian system.) But let's assume that there would be also a base-files-usrmerge package just to provide the links, to be installed later: how could this be automated by the converter package, since dpkg does not support being invoked by itself? > - 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. This would definitely be the best solution, but it requires to stop supporting non-merged systems. > 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". This would not be useful: a partially merged system does not provide any of the benefits of merged systems. Another option is agreeing that this cannot be fixed in a sane and practical way until non-merged systems have to be supported, and document somewhere that if anybody does this install-remove-reinstall dance on a libc-* package then they will have to run again the conversion program. -- ciao, Marco
signature.asc
Description: PGP signature