Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Thanks for the review, Jonathan.
On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:
> Sven Joachim wrote:
>
>> - 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)?
Ouch. It should not have been; I made a mistake while rebasing the
patches, because the target dir in libc.install needs to be set to
RTLDDIR, not to /lib.
> [...]
>> @@ -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?
Probably, but I guess it does not matter in practice.
DPKG_MAINTSCRIPT_ARCH is exported by dpkg since 1.15.4, and old dpkg
versions don't support multiarch so you have to do something totally
weird to install a foreign libc6.
>> 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.
Ah, I wasn't aware of that. Still, adding a Pre-Depends on dpkg 1.16.1
on the affected arches is probably not a good idea.
>> +#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.
Good idea. Something like that:
aside=$(mktemp -d /lib64-moved-by-libc6-prerm.XXXXXX)
echo "Moving /lib64 aside to $aside"
mv /lib64 $aside
I have some private undertakings tomorrow, will likely send a new patch
series on Monday, unless somebody beats me to it.
Cheers,
Sven
--
I still say "/lib64" is one of the nastiest pieces of shit I've ever
heard of.
-- Branden Robinson
Reply to: