* 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 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.
> 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.
Mihai
[0] {primary arch,secondary arch}
signature.asc
Description: OpenPGP digital signature
_______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
