Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Quick thoughts.
Sven Joachim wrote:
> + ldfile=$(readlink -e RTLD_SO)
> + # Test if libc is of the same architecture as coreutils
> + # If not, they almost surely have a multiarch system and we can use
> + # the native ELF interpreter
> + if ! $ldfile /bin/true 2>/dev/null; then
> + interpreter=
> + else
> + interpreter=$ldfile
> + fi
Very neat.
[...]
> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR rather than /lib
[...]
> --- a/debian/debhelper.in/libc.install
> +++ b/debian/debhelper.in/libc.install
> @@ -1,4 +1,4 @@
> -TMPDIR/lib/*.so* /lib
> +TMPDIR/RTLDDIR/*.so* /lib
> TMPDIR/SLIBDIR/*.so* SLIBDIR
> TMPDIR/LIBDIR/gconv/* LIBDIR/gconv
>
> diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
> index 18f1800..36d7ee7 100644
> --- a/debian/rules.d/build.mk
> +++ b/debian/rules.d/build.mk
[...]
> - link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
> + link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
> target="$(call xx,slibdir)/$$(readlink debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so)" ; \
> + mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
> ln -s $$target $$link_name ; \
Do I understand correctly that this is this a no-op (to prepare for
patch 5)?
[...]
> @@ -384,6 +404,13 @@ fi
> #DEBHELPER#
>
> if [ -n "$preversion" ]; then
> + if test -L /lib64; then
> + case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
> + amd64 | ppc64 | sparc64 | s390x)
> + remove_lib64_symlink ;;
> + esac
> + fi
If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
wrong value. Would it be possible to introduce a variable in
debian/rules.d/debhelper.mk so the right value can be cooked in at
build time?
> Subject: [PATCH 6/6] Restore the /lib64 symlink on downgrades
>
> It would be more prudent to prevent the downgrade from happening, but
> if we fail the prerm script, the one from the previous version kicks
> in and succeeds.
Fixed by dpkg commit 9d3ec0f5 (“dpkg: do not fallback to "new-prerm
failed-upgrade" for downgrades”). Probably that's too new to count
on.
> +#Downgrading from a version with a /lib64 directory to a version with
> +# a /lib64 symlink is extremely dangerous. We need to blow away the
> +# directory and restore the symlink, otherwise the dynamic linker gets
> +# lost after unpacking the replacing version.
> +
> + ldfile=$(readlink -e RTLD_SO)
> + # Test if libc is of the same architecture as coreutils
> + # If not, they almost surely have a multiarch system and we can use
> + # the native ELF interpreter
> + if ! $ldfile /bin/true 2>/dev/null; then
> + interpreter=
> + else
> + interpreter=$ldfile
> + fi
> +
> + # sync before and after the operation to reduce the danger of hosing
> + # the system
> + sync
> + rm -rf /lib64
> + $interpreter /bin/ln -s /lib /lib64
Maybe it would be possible to mv /lib64 somewhere and loudly let the
admin know about it if it contains anything more than the dynamic
linker.
Remaining problems:
- disruption to anything running concurrently with the
upgrade/downgrade. In the general case, there's nothing one can do
about this except warn about it.
- what happens if someone (a) has been trying to load libraries by
filename in /lib64 or (b) has been installing libraries to /lib64
and expecting to find them there?
Most likely, that's not a big deal --- I would expect people to have
used /usr/local/lib64 or /usr/lib64, but not /lib64.
- What happens to the /usr/lib64 symlink?
Except where mentioned above, it looks good to me (though I haven't
tested yet). Thanks!
Reply to: