On Wed, 19 Jun 2019 12:52:18 +0200 Mihai Moldovan wrote:

>* On 6/18/19 3:27 PM, Lars Wendler wrote:
>> IMHO you should NAK such a patch as this is definitely an issue
>> coming from our 17.1 profile's new lib directory structure.
>> If you commit the suggested patch, all 32bit 17.1 profile
>> installations will suffer from the bug our 64bit 17.1 profile
>> installations currently suffer from.  
>
>Can you elaborate on that, please? I understand that there's potential
>for breakage with a compat symlink. One example would be software that
>is not correctly trimmed to using lib32 instead of lib and hence
>trying to use the wrong, 64-bit, directory at compile time, unless
>additional patching is done.

I was reading the suggested patch wrong. I thought it
replaces /usr/lib/misc with /usr/lib64/misc bit I just saw that the
latter path was rather added to the list.

>I fail to see a lot of breakage potential with the current patch I
>applied that favors lib64. Let's create a matrix:
>
> System | 32-bit OpenSSH installed | 64-bit OpenSSH installed |
> [G]ood/[B]ad
>--------+--------------------------+--------------------------+---------------
>{32}    |           X              |             -            |       G
>{32}    |           -              |             X            | B
>(nonsense) {32}    |           X              |
>X            | B (nonsense?) {64}    |           X
>|             -            | B (nonsense) {64}    |
>-              |             X            |       G {64}
>|           X              |             X            | G (nonsense?)
>{32,64} |           X              |             -            |
>G {32,64} |           -              |             X
>|       B {64,32} |           X              |
>-            |       B {64,32} |           -
>|             X            |       G {64,32} |
>X              |             X            | G (nonsense?)
>
>The failure cases are pretty rare and mostly boil down to users
>messing up their system - for instance, why would anyone install a
>64-bit version of OpenSSH on a 32-bit non-multilib system? The only
>cases that would be bad is having a 32-bit OpenSSH version installed
>on a {64,32} multilib system or a 64-bit OpenSSH version on a {32,64}
>multilib system - i.e., when the installed OpenSSH version does *not*
>match the primary arch. These cases should be very rare and indicate a
>hosed system to begin with.
>
>Additionally, none of these failure cases are actually fatal. A 32-bit
>OpenSSH sftp-server binary should work fine on a 64-bit system. As
>long as we actually find a binary, we should be mostly good to go.
>
>
>> We changed the following directories on 64bit arches with the 17.1
>> profile:
>> 
>> 17.0:
>> 
>> # ls -ld /lib*
>> lrwxrwxrwx 1 root root    5 May 17 10:24 /lib -> lib64
>> drwxr-xr-x 1 root root 1174 May 17 10:26 /lib32
>> drwxr-xr-x 1 root root 5078 Jun 13 18:50 /lib64
>> 
>> 
>> 17.1:
>> 
>> # ls -ld /lib*
>> drwxr-xr-x 1 root root 1382 May 13 22:54 /lib
>> drwxr-xr-x 1 root root 5340 Jun 18 10:23 /lib64
>> 
>> 
>> As you can see, "lib32" became "lib" and "lib" is no longer a symlink
>> pointing to "lib64".  
>
>Hmm, that's just nitpicking maybe and too late for any change now that
>the profile went on to be stable, but I don't get why lib32 was
>renamed to lib. Wouldn't it have been better to just keep lib32 and
>lib64 around (which describes both directories's purpose vividly) and
>just remove the compat symlink? Just using "lib" is ambiguous and can
>be confusing.

IIRC it was an attempt to remove the lib symlinks. Unfortunately I
haven't found the original post about why that change was introduced
anymore or why it was done this way. All I can remember is some talking
about "other distros are doing it likewise".

>
>> My suggestion is to let the Gentoo package maintainers handle this in
>> the affected x2go package's ebuild files. We have a function called
>> "get_libdir" that can be used with sed to set the correct lib dir
>> name in the affected code.  
>
>I could implement a Makefile variable that is being passed down via
>CFLAGS (no sed hackery) and add it as the first option. I'd like to
>keep the fallback list, though. Not sure if that would actually be
>really useful to anyone, though.

Not necessary. If both paths are present I suppose there will be no
more regressions.

>Mihai
>
>[0] {primary arch,secondary arch}
>

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39