Bug#367962: Please don't ship a /lib64 symlink in the package on amd64

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Andreas Jochens <aj@andaco.de> writes:

> Hello Aurelien,
>
> On 06-May-19 04:15, Aurelien Jarno wrote:
>> [Ccing: amd64 and dpkg developers as they are concerned by this subject]
>> Currently the (/usr)/lib64 -> /lib symlink is shipped in the libc6 
>> package. Goswin von Brederlow asked for this link to be created in the 
>> postinst instead, so that packages could install files in both 
>> (/usr)/lib and (/usr)/lib64 directories.
>> 
>> 
>> Could you please give me your opinion on that, so that I can take a 
>> decision?
>
> please do not change the status quo regarding the lib64 symlinks.
>
> During the porting of Debian to amd64 quite a few alternatives
> regarding the lib64 issue were discussed and tested. The biarch approach 
> with /usr/lib and /usr/lib64 as two different directories failed badly.

I'm not suggesting splitting the dirs. Just the way the link is setup.

I'm suggesting creating it in the maintainer scripts instead of the
data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
libc6 unupgradable.

>> I have concerns about that:
>> - I don't really want to add something specific to amd64 in postinst. 
>> But ok, that's not an argument.
>> - I am not sure that creating the link in postinst will work. Creating 
>> it in preinst looks safer to me.
>> - If you can install files in (/usr)/lib64, the files will end up in 
>> (/usr)/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 (/usr)/lib and 
>> (/usr)/lib64, then the files will be overwritten without warning. This 
>> is IMHO not acceptable.
>
> I share these concerns.
>
>
> The current policy which requires all packages to install native 
> amd64 libraries in /usr/lib is simple and sane. This should not be
> changed. 
>
> Anything which makes it easier to violate this simple policy
> will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently
> to problems which could be difficult to disentangle later.

The goal would be to actualy get everything into (/usr)/lib64 while
intermittendly allowing a mixed usage. That would allow for FHS
compliance for 32bit libraries shiped in lib32gcc1, lib32stdc++*,
lib32asound, ia32-libs and more to come.

> This is just my personal opinion.
>
> Regards
> Andreas Jochens

MfG
        Goswin