Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Aurelien Jarno <aurelien@aurel32.net> writes:
> severity 367962 wishlist
> thanks
>
> Goswin Brederlow wrote:
>> Package: libc6
>> Version: 2.3.6-7
>> Severity: normal
>> Hi,
>> Currently the libc6 package on amd64 ships a symlink from /lib64 to
>> /lib (and /usr/lib64). While the symlink is needed for things to work
>> shipping it in the data.tar.gz makes it impossible for any package to
>> put files into /lib64 or /usr/lib64 (as specified by FHS):
>> If any package does so the next time libc6 gets updated you get an
>> error similar to:
>> dpkg: error processing foo1-1.0.deb (--install):
>> trying to overwrite `/foo', which is also in package foo2
>> Instead of shipping the symlinks I suggest creating them in the
>> preinst (if they don't exist) and shipping at least one file
>> (/lib64/ld-2.3.2.so comes to mind) in /lib64 and /usr/lib64 to prevent
>> dpkg from removing the links on updates.
>> Why would we want this?
>> With that change packages can be patched (or un-patched) to use the
>> FHS compliant lib64 dirs. Libraries and plugins are then in a
>> different directory than on i386 alowing for automatic conversion of
>> amd64 packages to an i386 based bi-arch system.
>> Also if enough packages get changed to /lib64 the symlinks could be
>> droped and bugs filed against the remaining packages. Updating to a
>> non symlinks way might be tricky but at least new installs would get
>> the right dirs.
>>
>
> I don't really understand here. When I tried to swap the directory and
> the symlink, I have been told, that we don't have to do that, as
Swaping around wouldn't have worked since then libc6 would be
uninstallable if any package has a file in /lib or /usr/lib. Using
only /lib64 and /usr/lib64 would break too many existing packages so
that isn't an option either.
For now the only option is to not ship a symlink (be that lib -> lib64
or lib64 -> lib) but still create one in preinst.
> Debian will never be compliant with the FHS. So why do you wan't to be
> FHS compliant now?
The system (64 bit only) as such is compliant since libc6 provides the
link. Each package is not since they dump 64bit libraries in /lib and
/usr/lib.
My intention is to seperate out 32bit stuff in lib and 64bit stuff in
lib64 so that they comply with the FHS for each seperate package and
can possibly be resorted into multiarch dirs by a conversion
script. In this case the right thing to do is also the more helpfull
one. But we will never be able to split lib and lib64 dirs on the
filesystem if packages don't use them in the data.tar.gz first.
At work we sell Debian based clusters with a 32/64bit biarch setup
with automaticaly converted sarge packages but since both use /lib
and /usr/lib anything with plugins can't work in both bit sizes. If
packages can use /lib64 and /usr/lib64 I can send in patches for all
of them and get them working for etch.
Also upstream sources are using lib64 more and more and Debian has to
patch it back to lib again. Every time some package upstream changes
to lib64 the libc6 package becomes unupgradable because it tries to
overwrite some packages /lib64 or /usr/lib64 directory with a symlink
and the other package has to be fixed. I think 5 or 6 users have
already encountered such a bug this year.
I would have liked to go directly to multiarch dirs but resistance
from people, including the glibc and gcc teams, made that unlikely to
happen even partialy for etch. Using lib64 now will make it much
easier to change the dir to the multiarch name later if it is done
with a proper abstraction (put the libdir in variable so only one
place needs changing). Multiarch won't come in one big wave so now I'm
trying to do it in many little steps.
MfG
Goswin
Reply to: