Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
Aurelien Jarno <aurelien@aurel32.net> writes:
>> 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.
>
> So you in short you mean you want to allow, even temporarily to have
> both 32-bit and 64-bit libraries in /lib? That sucks.
Aeh, no. As long as lib and lib64 are the same destination 32bit has
to stay out of there. But once we get all 64bit stuff into lib64 (or a
majority) a split can be atempted.
> I don't know where you have seen resistance from the glibc. We have
> uploaded a package ready from multiarch (with libc6 binaries splitted
> into libc-bin). But it has been rejected by the ftp masters. After
> seeing to much resistance, I have decided to stop on that. But I have
> always claimed that patches are welcomes, *if* you get an agreement
> from the ftpmasters and the release team. I don't want to spend my
> time on that.
>
> So please don't say we are making resistance.
True. You have helped there. But even you were restistant to using the
multiarch dirs (the x86_64-linux-gnu dirs). I'm talking about the dirs
specificaly and not the wider multiarch iossues.
>> 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.
>>
>
> Well I don't see how it would help the transition to multiarch. The
> library path in multiarch is different, so the package would have to
> be changed again anyway.
Because packages will be prepared to handle different libdirs. All
that needs to be changed is the name of the libdir and not the
handling for different names. For most packages this involves adding
*.in files for debhelper (e.g. libfoobar.install) files.
> So here are my concerns about that:
> - I don't really want to add something specific to amd64 in
> postinst. But ok, that's not an argument.
> - If you can install files in /lib64, the files will end up in
> /lib. And dpkg won't know anything about them. dpkg -S and other tools
> won't work correctly.
> - If you have two packages providing the same files in /lib and
> /lib64, then the files will be overwritten without warning. This is
> not acceptable.
That is a good point. I will have to test that. Not so much that you
don't get a warning on overwrite (many systems have the default
--force-overwrite option in dpkg.conf anyway) but it could be that
upgrading from /lib to /lib64 in a package might loose the files
(/lib64/foobar gets installed, then /lib/foobar gets removed).
> That's why I am not in favor of that, but I am not able to take the
> decision. I will send a mail to debian-devel to ask about more
> opinions.
>
> Bye,
> Aurelien
MfG
Goswin
Reply to: