[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-03 Thread Martin Vaeth
Michał Górny  wrote:
>
> I have been running such a layout for over a year. [...]

Thanks for clarifying that this already was discussed.
Obviously, I was not aware about this discussion, and perhaps
I was not the only one.

> instead of waking up last-minute to redesign [...]

Pointing me to the discussion would have been sufficient:
If this was already discussed, it makes no sense to open
that bottle again.
As mentioned in my first posting:
In this case I am sorry for the noise.




Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-03 Thread Michał Górny
On czw, 2017-08-03 at 07:50 +, Martin Vaeth wrote:
> Mike Gilbert  wrote:
> > Debian puts 64-bit libs in /lib/(host)
> 
> Yes, this is somewhat weird:
> They have /lib/i386-linux-gnu/ and /lib/x86_64-linux-gnu/
> but anyway they use /lib32 instead of e.g. /lib/i686-linux-gnu/
> Their reasons for this are mysterious to me.
> 
> > Migrating Gentoo to a "multiarch" config is a larger project.
> 
> Migrating to the completely split setting /lib{,32,64,x32}
> would be _less_ intrusive than to simultaneously omitting /lib32:
> With a slight modification of Michał's tool (in the instructions
> and keeping lib32 untouched) not even a re-emerge of anything
> would be necessary (as is the case now).

I have been running such a layout for over a year. I've stopped when
base-system proactively blocked it in baselayout, and multiple people
in Gentoo rejected providing support for it.

> This is one of the reasons why a completely split layout appears
> safer to me than to combine it with yet another new merge we
> have no experience with.

Except that it breaks every 32-bit x86 pre-built executable.

Anyway, this is off-topic and a waste of everyone's time. Please review
the tool instead of waking up last-minute to redesign everything that's
been designed for 10+ years.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-03 Thread Martin Vaeth
Mike Gilbert  wrote:
> Debian puts 64-bit libs in /lib/(host)

Yes, this is somewhat weird:
They have /lib/i386-linux-gnu/ and /lib/x86_64-linux-gnu/
but anyway they use /lib32 instead of e.g. /lib/i686-linux-gnu/
Their reasons for this are mysterious to me.

> Migrating Gentoo to a "multiarch" config is a larger project.

Migrating to the completely split setting /lib{,32,64,x32}
would be _less_ intrusive than to simultaneously omitting /lib32:
With a slight modification of Michał's tool (in the instructions
and keeping lib32 untouched) not even a re-emerge of anything
would be necessary (as is the case now).

This is one of the reasons why a completely split layout appears
safer to me than to combine it with yet another new merge we
have no experience with.




[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-03 Thread Martin Vaeth
Michał Górny  wrote:
>
> 'No mainstream' as you claim it doesn't mean it's fine to invent yet
> another completely incompatible solution.

As I understand, the compatibility with Debian might be increased
(keeping /lib32), at the cost of slightly decreasing the compatibility
with Red Hat (concerning 32bit emulation).
So depending on the use case, it might as well be more compatible.

>> in _all_ /lib* directories
>
> This is not true.

You are right, I had made a stupid mistake. (I forgot that I still
have the symlink lib->lib64 so that of course I should not have
wondered why all ld-* existed in both libs...)

> the linker uses /lib path independently of how multilib is done
> on the system.

I am not sure whether I understand what you mean.
Do you mean that practically sys-libs/binutils or sys-libs/glibc
have hardcoded
/lib -> 32bit
/lib64 -> 64bit
(concerning ld-*) unless one patches it out?
In this case you are right that there is an upstream to follow.
In this case I wonder why Debian decided to patch out this
upstream decision to support /lib32.

> The 32-bit proprietary binaries use exactly /lib which is the main
> reason for the switch.

I thought the main reason for the switch is to avoid the
merging of /lib and /lib64 which in bug 506276 led to problems
for debugging.
For this reason I am afraid that now merging /lib and /lib32
might again lead to a similar type of problems.
I am aware that exactly the cited problem is now mitigated,
because this time the merging does not happen over a symlink.
But anyway, it seems unnatural when "curing" from a merge to
decide to merge something else.




Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-03 Thread Michał Górny
On śro, 2017-08-02 at 21:02 -0400, Walter Dnes wrote:
> On Wed, Aug 02, 2017 at 03:25:01PM -0400, Mike Gilbert wrote
> > On Wed, Aug 2, 2017 at 3:07 PM, Martin Vaeth  wrote:
> > > Mike Gilbert  wrote:
> > > > On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth  wrote:
> > > > > If this already was discussed then sorry for the noise:
> > > > > 
> > > > > What is the rationale for merging lib32 with lib?
> > > > > Wouldn't it be somewhat cleaner to have a completely
> > > > > split structure
> > > > > 
> > > > > lib64
> > > > > lib32
> > > > > libx32 (possibly)
> > > > > lib
> > > > 
> > > > Here are a couple of reasons:
> > > > 
> > > > 1. Other distros (notably Red Hat and Fedora) put 32-bit libs in "lib".
> > > 
> > > According to bug 506276, Debian has instead merged 64-bit to lib.
> > > So it seems to me that there is no "mainstream" to follow.
> > > Perhaps striving for the cleanest solution would be the best?
> > 
> > Debian puts 64-bit libs in /lib/(host), where (host) is something like
> > x86_64-linux-gnu. They don't get put in /lib directly. They call this
> > "multiarch".
> > 
> > Migrating Gentoo to a "multiarch" config is a larger project.
> 
>   And what happens when 128-bit cpus debut? /lib128?

Then we use whatever path is used in the appropriate ABI.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Benda Xu
"Walter Dnes"  writes:

>   And what happens when 128-bit cpus debut? /lib128?

In this case CHOST makes more sense.  From my understanding, the Exherbo
approach is the cleanest.

Benda



Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Walter Dnes
On Wed, Aug 02, 2017 at 03:25:01PM -0400, Mike Gilbert wrote
> On Wed, Aug 2, 2017 at 3:07 PM, Martin Vaeth  wrote:
> > Mike Gilbert  wrote:
> >> On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth  wrote:
> >>> If this already was discussed then sorry for the noise:
> >>>
> >>> What is the rationale for merging lib32 with lib?
> >>> Wouldn't it be somewhat cleaner to have a completely
> >>> split structure
> >>>
> >>> lib64
> >>> lib32
> >>> libx32 (possibly)
> >>> lib
> >>
> >> Here are a couple of reasons:
> >>
> >> 1. Other distros (notably Red Hat and Fedora) put 32-bit libs in "lib".
> >
> > According to bug 506276, Debian has instead merged 64-bit to lib.
> > So it seems to me that there is no "mainstream" to follow.
> > Perhaps striving for the cleanest solution would be the best?
> 
> Debian puts 64-bit libs in /lib/(host), where (host) is something like
> x86_64-linux-gnu. They don't get put in /lib directly. They call this
> "multiarch".
> 
> Migrating Gentoo to a "multiarch" config is a larger project.

  And what happens when 128-bit cpus debut? /lib128?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Michał Górny
On śro, 2017-08-02 at 19:07 +, Martin Vaeth wrote:
> Mike Gilbert  wrote:
> > On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth  wrote:
> > > If this already was discussed then sorry for the noise:
> > > 
> > > What is the rationale for merging lib32 with lib?
> > > Wouldn't it be somewhat cleaner to have a completely
> > > split structure
> > > 
> > > lib64
> > > lib32
> > > libx32 (possibly)
> > > lib
> > 
> > Here are a couple of reasons:
> > 
> > 1. Other distros (notably Red Hat and Fedora) put 32-bit libs in "lib".
> 
> According to bug 506276, Debian has instead merged 64-bit to lib.
> So it seems to me that there is no "mainstream" to follow.
> Perhaps striving for the cleanest solution would be the best?

'No mainstream' as you claim it doesn't mean it's fine to invent yet
another completely incompatible solution.

> > 2. The path to the 32-bit runtime linker (/lib/ld-linux.so.2) is
> > hard-coded in every x86 binary on your system.
> 
> I am afraid that these must stay exceptional in any case:
> Also currently, gentoo (and if I understood correctly, also Debian
> and Red Hat) has the possible ld-linux{,-x86-64,-x32}.so.2 symlinks
> in _all_ /lib* directories; I suppose that this is not intended to
> change. (I assume that a change might break some proprietary binaries
> which might have hard-coded the "wrong" directory.)

This is not true.

$ ls /lib*/ld-linux*
/lib64/ld-linux-x86-64.so.2  /lib/ld-linux.so.2  /libx32/ld-linux-x32.so.2

The only symlinks ever there was in /lib64 because of the Gentoo symlink
deviation.

The 32-bit proprietary binaries use exactly /lib which is the main
reason for the switch. Plus, the linker uses /lib path independently of
how multilib is done on the system.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Mike Gilbert
On Wed, Aug 2, 2017 at 3:07 PM, Martin Vaeth  wrote:
> Mike Gilbert  wrote:
>> On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth  wrote:
>>> If this already was discussed then sorry for the noise:
>>>
>>> What is the rationale for merging lib32 with lib?
>>> Wouldn't it be somewhat cleaner to have a completely
>>> split structure
>>>
>>> lib64
>>> lib32
>>> libx32 (possibly)
>>> lib
>>
>> Here are a couple of reasons:
>>
>> 1. Other distros (notably Red Hat and Fedora) put 32-bit libs in "lib".
>
> According to bug 506276, Debian has instead merged 64-bit to lib.
> So it seems to me that there is no "mainstream" to follow.
> Perhaps striving for the cleanest solution would be the best?

Debian puts 64-bit libs in /lib/(host), where (host) is something like
x86_64-linux-gnu. They don't get put in /lib directly. They call this
"multiarch".

Migrating Gentoo to a "multiarch" config is a larger project.



[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Martin Vaeth
Mike Gilbert  wrote:
> On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth  wrote:
>> If this already was discussed then sorry for the noise:
>>
>> What is the rationale for merging lib32 with lib?
>> Wouldn't it be somewhat cleaner to have a completely
>> split structure
>>
>> lib64
>> lib32
>> libx32 (possibly)
>> lib
>
> Here are a couple of reasons:
>
> 1. Other distros (notably Red Hat and Fedora) put 32-bit libs in "lib".

According to bug 506276, Debian has instead merged 64-bit to lib.
So it seems to me that there is no "mainstream" to follow.
Perhaps striving for the cleanest solution would be the best?

> 2. The path to the 32-bit runtime linker (/lib/ld-linux.so.2) is
> hard-coded in every x86 binary on your system.

I am afraid that these must stay exceptional in any case:
Also currently, gentoo (and if I understood correctly, also Debian
and Red Hat) has the possible ld-linux{,-x86-64,-x32}.so.2 symlinks
in _all_ /lib* directories; I suppose that this is not intended to
change. (I assume that a change might break some proprietary binaries
which might have hard-coded the "wrong" directory.)




[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Holger Hoffstätte
On Wed, 02 Aug 2017 17:51:43 +, Martin Vaeth wrote:

> Michał Górny  wrote:
>>
>> What are your thoughts?
> 
> If this already was discussed then sorry for the noise:
> 
> What is the rationale for merging lib32 with lib?
> Wouldn't it be somewhat cleaner to have a completely
> split structure
> 
> lib64
> lib32
> libx32 (possibly)
> lib

I wondered the same. If anything it would make more sense to merge
lib64 into lib, since it's the platform's default (assuming 64bit).
Merging lib32 into lib is going to cause nothing but problems.

-h




Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Mike Gilbert
On Wed, Aug 2, 2017 at 1:51 PM, Martin Vaeth  wrote:
> Michał Górny  wrote:
>>
>> What are your thoughts?
>
> If this already was discussed then sorry for the noise:
>
> What is the rationale for merging lib32 with lib?
> Wouldn't it be somewhat cleaner to have a completely
> split structure
>
> lib64
> lib32
> libx32 (possibly)
> lib

Here are a couple of reasons:

1. Other distros (notably Red Hat and Fedora) put 32-bit libs in "lib".
2. The path to the 32-bit runtime linker (/lib/ld-linux.so.2) is
hard-coded in every x86 binary on your system.



[gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Martin Vaeth
Michał Górny  wrote:
>
> What are your thoughts?

If this already was discussed then sorry for the noise:

What is the rationale for merging lib32 with lib?
Wouldn't it be somewhat cleaner to have a completely
split structure

lib64
lib32
libx32 (possibly)
lib