[gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Michał Górny]

Hello, everyone.

I've finally gotten around to wrapping up my multilib setup
in a profile, and providing necessary patches to system packages
to make it possible to use it without having to hack their mistaken
logic around.

The profile is called 'no-lib-symlink', and is provided as an alternate
amd64 variant. Unlike the common profiles, it is based on three lib*
directories: lib32 for 32-bit binaries, lib64 for 64-bit binaries
and lib as a directory for software packages only (the new-style
libexec).

Please note that this is not the goal layout Gentoo should be working
towards. In that layout, 'lib' needs to be used for 32-bit binaries for
ABI compatibility's sake. My layout is rather targeted at developers who
can benefit from having a clear split on where packages install files,
and therefore being able to catch mistakes such as using 'lib' and
$(get_libdir) interchangeably.

This batch of patches includes also three patches for base system
packages:

a. a patch to prevent glibc from overriding LIBDIR* variables set by
profiles. The logic used there is probably used for cross-compiling,
and so it is moved into cross-compiling branch of code.

b. a patch to fix 'else' branch of baselayout for SYMLINK_LIB=no
systems. For some reason, this branch created 'lib' symlink when 'lib'
did not exist -- therefore triggering another branch of code on next
baselayout installation that replaced the symlink with a directory.
The patch changes it to create the directory instead.

c. a patch to prevent baselayout from complaining when both lib
and lib32 are separate directories. In order to cover that case while
preserving compatibility with the original intent, it skips
the complaint when lib32 is considered a valid directory as well as lib.


--
Best regards,
Michał Górny

---

Michał Górny (4):
  sys-libs/glibc: Do not reset multilib vars unless cross-compilnig,
#588368
  sys-apps/baselayout: Fix SYMLINK_LIB=no to create lib dir instead of
sym
  sys-apps/baselayout: Do not complain about lib+lib32 when it is valid
  profiles: Add an amd64 no-lib-symlink profile

 profiles/arch/amd64/no-lib-symlink/make.defaults| 2 ++
 profiles/arch/amd64/no-lib-symlink/parent   | 1 +
 profiles/default/linux/amd64/13.0/no-lib-symlink/parent | 2 ++
 profiles/profiles.desc  | 1 +
 sys-apps/baselayout/baselayout-2.2-r1.ebuild| 6 ++
 sys-libs/glibc/files/eblits/common.eblit| 3 ++-
 6 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 profiles/arch/amd64/no-lib-symlink/make.defaults
 create mode 100644 profiles/arch/amd64/no-lib-symlink/parent
 create mode 100644 profiles/default/linux/amd64/13.0/no-lib-symlink/parent

-- 
2.9.0

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Mike Gilbert]

On Sat, Jul 9, 2016 at 5:01 PM, Michał Górny  wrote:
> I've finally gotten around to wrapping up my multilib setup
> in a profile, and providing necessary patches to system packages
> to make it possible to use it without having to hack their mistaken
> logic around.

The baselayout and glibc changes seem like a good idea.

I don't see much value in creating a new profile though; it's easy
enough for a developer to just stick SYMLINK_LIB=no in make.conf.

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Michał Górny]

On Mon, 11 Jul 2016 12:33:54 -0400
Mike Gilbert  wrote:

> On Sat, Jul 9, 2016 at 5:01 PM, Michał Górny  wrote:
> > I've finally gotten around to wrapping up my multilib setup
> > in a profile, and providing necessary patches to system packages
> > to make it possible to use it without having to hack their mistaken
> > logic around.  
> 
> The baselayout and glibc changes seem like a good idea.
> 
> I don't see much value in creating a new profile though; it's easy
> enough for a developer to just stick SYMLINK_LIB=no in make.conf.

I didn't initially wanted to do the profile either but some developers
have refused to support this 'unsupported configuration'. I assume that
having an official profile will ensure better cooperation.

-- 
Best regards,
Michał Górny



pgp0TkMPG3XXh.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Mike Gilbert]

On Mon, Jul 11, 2016 at 1:46 PM, Michał Górny  wrote:
> On Mon, 11 Jul 2016 12:33:54 -0400
> Mike Gilbert  wrote:
>
>> On Sat, Jul 9, 2016 at 5:01 PM, Michał Górny  wrote:
>> > I've finally gotten around to wrapping up my multilib setup
>> > in a profile, and providing necessary patches to system packages
>> > to make it possible to use it without having to hack their mistaken
>> > logic around.
>>
>> The baselayout and glibc changes seem like a good idea.
>>
>> I don't see much value in creating a new profile though; it's easy
>> enough for a developer to just stick SYMLINK_LIB=no in make.conf.
>
> I didn't initially wanted to do the profile either but some developers
> have refused to support this 'unsupported configuration'. I assume that
> having an official profile will ensure better cooperation.
>

I'm doubtful that will help with stubborn people, but I guess it can't
hurt to try it.

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Ulrich Mueller]

> On Mon, 11 Jul 2016, Michał Górny wrote:

> I didn't initially wanted to do the profile either but some
> developers have refused to support this 'unsupported configuration'.
> I assume that having an official profile will ensure better
> cooperation.

IMHO we should create additional profiles only if there are valid
technical reasons, but not because of social reasons.

Even more so as the profile in question is intended to be used by
developers only.

Ulrich


pgpfV2Bo0bmmR.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Michał Górny]

On Tue, 12 Jul 2016 07:29:08 +0200
Ulrich Mueller  wrote:

> > On Mon, 11 Jul 2016, Michał Górny wrote:  
> 
> > I didn't initially wanted to do the profile either but some
> > developers have refused to support this 'unsupported configuration'.
> > I assume that having an official profile will ensure better
> > cooperation.  
> 
> IMHO we should create additional profiles only if there are valid
> technical reasons, but not because of social reasons.
> 
> Even more so as the profile in question is intended to be used by
> developers only.

Like the 'developer' profile?

But I guess there's no need for explicit profile when the changes can
be easily done via make.conf. At least for the moment. However,
the three remaining patches still stand.

-- 
Best regards,
Michał Górny



pgp6VsKMoscgz.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Michał Górny]

On Sat,  9 Jul 2016 23:01:24 +0200
Michał Górny  wrote:

> Hello, everyone.
> 
> I've finally gotten around to wrapping up my multilib setup
> in a profile, and providing necessary patches to system packages
> to make it possible to use it without having to hack their mistaken
> logic around.
> 
> The profile is called 'no-lib-symlink', and is provided as an alternate
> amd64 variant. Unlike the common profiles, it is based on three lib*
> directories: lib32 for 32-bit binaries, lib64 for 64-bit binaries
> and lib as a directory for software packages only (the new-style
> libexec).
> 
> Please note that this is not the goal layout Gentoo should be working
> towards. In that layout, 'lib' needs to be used for 32-bit binaries for
> ABI compatibility's sake. My layout is rather targeted at developers who
> can benefit from having a clear split on where packages install files,
> and therefore being able to catch mistakes such as using 'lib' and
> $(get_libdir) interchangeably.
> 
> This batch of patches includes also three patches for base system
> packages:
> 
> a. a patch to prevent glibc from overriding LIBDIR* variables set by
> profiles. The logic used there is probably used for cross-compiling,
> and so it is moved into cross-compiling branch of code.
> 
> b. a patch to fix 'else' branch of baselayout for SYMLINK_LIB=no
> systems. For some reason, this branch created 'lib' symlink when 'lib'
> did not exist -- therefore triggering another branch of code on next
> baselayout installation that replaced the symlink with a directory.
> The patch changes it to create the directory instead.
> 
> c. a patch to prevent baselayout from complaining when both lib
> and lib32 are separate directories. In order to cover that case while
> preserving compatibility with the original intent, it skips
> the complaint when lib32 is considered a valid directory as well as lib.
> 
> 
> --
> Best regards,
> Michał Górny
> 
> ---
> 
> Michał Górny (4):
>   sys-libs/glibc: Do not reset multilib vars unless cross-compilnig,
> #588368
>   sys-apps/baselayout: Fix SYMLINK_LIB=no to create lib dir instead of
> sym
>   sys-apps/baselayout: Do not complain about lib+lib32 when it is valid

Committed those three now.

>   profiles: Add an amd64 no-lib-symlink profile

Abandoned this one.

-- 
Best regards,
Michał Górny



pgpWwQFQRj_S5.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Joshua Kinard]

On 07/09/2016 17:01, Michał Górny wrote:
> Hello, everyone.
> 
> I've finally gotten around to wrapping up my multilib setup
> in a profile, and providing necessary patches to system packages
> to make it possible to use it without having to hack their mistaken
> logic around.
> 
> The profile is called 'no-lib-symlink', and is provided as an alternate
> amd64 variant. Unlike the common profiles, it is based on three lib*
> directories: lib32 for 32-bit binaries, lib64 for 64-bit binaries
> and lib as a directory for software packages only (the new-style
> libexec).

[snip]

Responding late to this.  This change won't, in the future, affect mips
multilib, will it?  Remember, we've got three ABIs to juggle, and this proposed
change looks like it might clobber one of those ABIs.

o32 - old 32-bit, goes into /lib or /usr/lib.
n32 - hybrid 32-bit/64-bit (like x32), goes into /lib32 or /usr/lib32.
n64 - full 64-bit, goes into /lib64 or /usr/lib64

This basically follows the layout that old IRIX used to use when you had
binaries/libs from all three ABIs mixed into the same root.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers

[Michał Górny]

On Mon, 5 Sep 2016 07:47:53 -0400
Joshua Kinard  wrote:

> On 07/09/2016 17:01, Michał Górny wrote:
> > Hello, everyone.
> > 
> > I've finally gotten around to wrapping up my multilib setup
> > in a profile, and providing necessary patches to system packages
> > to make it possible to use it without having to hack their mistaken
> > logic around.
> > 
> > The profile is called 'no-lib-symlink', and is provided as an alternate
> > amd64 variant. Unlike the common profiles, it is based on three lib*
> > directories: lib32 for 32-bit binaries, lib64 for 64-bit binaries
> > and lib as a directory for software packages only (the new-style
> > libexec).  
> 
> [snip]
> 
> Responding late to this.  This change won't, in the future, affect mips
> multilib, will it?  Remember, we've got three ABIs to juggle, and this 
> proposed
> change looks like it might clobber one of those ABIs.
> 
> o32 - old 32-bit, goes into /lib or /usr/lib.
> n32 - hybrid 32-bit/64-bit (like x32), goes into /lib32 or /usr/lib32.
> n64 - full 64-bit, goes into /lib64 or /usr/lib64
> 
> This basically follows the layout that old IRIX used to use when you had
> binaries/libs from all three ABIs mixed into the same root.

I don't think the patches I committed should cause any trouble for
mips. If at all, I think they are more likely to fix some imminent
trouble due to buggy transition logic.

-- 
Best regards,
Michał Górny



pgpH36G1Eahbu.pgp
Description: OpenPGP digital signature