On Aug 19, Aurelien Jarno <aurelien@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
Attachment:
signature.asc
Description: PGP signature