[gentoo-dev] rfc: libexec directory inconsistency

[gentoo-dev] rfc: libexec directory inconsistency

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

All,

I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be
$(get_libdir)/foo, which puts things in different directories depending on
whether the system is multilib or not.

I enquired from Robin why we do this, and I was told that libexec is
supposed to contain things which are not abi specific, but we do not
enforce that for /, even though we do for /usr.

Is there a reason for this? If not, would it break things if we start
using /libexec as well as /usr/libexec?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: rfc: libexec directory inconsistency

[Diego Elio Pettenò]

Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto:

> Is there a reason for this? If not, would it break things if we start
> using /libexec as well as /usr/libexec?

More or less and yes, it would create one more root directory that has
no real usage to be there anyway...

> I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be
> $(get_libdir)/foo, which puts things in different directories
> depending on whether the system is multilib or not.
> 

Which is wrong, it should be /lib/foo instead, not $(get_libdir), to
follow what udev and other software in Linux has been using for a very
long time now.

The one problem we have here is that for reason I don't know,
no-multilib profiles started using lib64 exclusively instead of the
(proper) lib exclusively...

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: rfc: libexec directory inconsistency

[Matthias Schwarzott]

Getting that discussion back on top.

On Samstag, 22. Januar 2011, Diego Elio Pettenò wrote:
> Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto:
> > Is there a reason for this? If not, would it break things if we start
> > using /libexec as well as /usr/libexec?
> 
> More or less and yes, it would create one more root directory that has
> no real usage to be there anyway...
> 
> > I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be
> > $(get_libdir)/foo, which puts things in different directories
> > depending on whether the system is multilib or not.
> 
> Which is wrong, it should be /lib/foo instead, not $(get_libdir), to
> follow what udev and other software in Linux has been using for a very
> long time now.

Sounds like we should fix udev ebuild and some ebuilds installing udev rules to 
not use /$(get_libdir)/udev, but plain /lib/udev.

I used that in believe that /lib is identical or links to /$(get_libdir) and 
multilib-strict requires it, but it seems to be intelligent enough to only 
deny 64-bit libs to go to /lib.

So proper udev should use /lib/udev, correct?

Matthias

Re: [gentoo-dev] Re: rfc: libexec directory inconsistency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

On Sun, 24 Apr 2011 21:43:16 +0200
Matthias Schwarzott <zzam@gentoo.org> wrote:

> Sounds like we should fix udev ebuild and some ebuilds installing
> udev rules to not use /$(get_libdir)/udev, but plain /lib/udev.
> 
> I used that in believe that /lib is identical or links
> to /$(get_libdir) and multilib-strict requires it, but it seems to be
> intelligent enough to only deny 64-bit libs to go to /lib.
> 
> So proper udev should use /lib/udev, correct?

Do you really think it'd be fine for some systems to possibly
have /lib64 and /lib with random different contents?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: libexec directory inconsistency

[Matthias Schwarzott]

On Sonntag, 24. April 2011, Michał Górny wrote:
> On Sun, 24 Apr 2011 21:43:16 +0200
> 
> Matthias Schwarzott <zzam@gentoo.org> wrote:
> > Sounds like we should fix udev ebuild and some ebuilds installing
> > udev rules to not use /$(get_libdir)/udev, but plain /lib/udev.
> > 
> > I used that in believe that /lib is identical or links
> > to /$(get_libdir) and multilib-strict requires it, but it seems to be
> > intelligent enough to only deny 64-bit libs to go to /lib.
> > 
> > So proper udev should use /lib/udev, correct?
> 
> Do you really think it'd be fine for some systems to possibly
> have /lib64 and /lib with random different contents?

Well I was always under the impression that /lib64 and /lib did point to the 
same directory.
Is the case where /lib is no symlink to /lib64 so frequent?

Matthias

Re: [gentoo-dev] Re: rfc: libexec directory inconsistency

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On Sun, 24 Apr 2011 22:38:13 +0200
Matthias Schwarzott <zzam@gentoo.org> wrote:

> On Sonntag, 24. April 2011, Michał Górny wrote:
> > On Sun, 24 Apr 2011 21:43:16 +0200
> > 
> > Matthias Schwarzott <zzam@gentoo.org> wrote:
> > > Sounds like we should fix udev ebuild and some ebuilds installing
> > > udev rules to not use /$(get_libdir)/udev, but plain /lib/udev.
> > > 
> > > I used that in believe that /lib is identical or links
> > > to /$(get_libdir) and multilib-strict requires it, but it seems
> > > to be intelligent enough to only deny 64-bit libs to go to /lib.
> > > 
> > > So proper udev should use /lib/udev, correct?
> > 
> > Do you really think it'd be fine for some systems to possibly
> > have /lib64 and /lib with random different contents?
> 
> Well I was always under the impression that /lib64 and /lib did point
> to the same directory.
> Is the case where /lib is no symlink to /lib64 so frequent?

Sorry for replying that late.

The 'main' multilib profile was switched to have 64-bit libs in lib64
and 32-bit ones in lib lately. I'm not sure if it used by any real
profile though.

And I think that non-multlib amd64 has lib64 only.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: libexec directory inconsistency

[Matthias Schwarzott]

On Sonntag, 24. April 2011, Michał Górny wrote:
> On Sun, 24 Apr 2011 21:43:16 +0200
> 
> Matthias Schwarzott <zzam@gentoo.org> wrote:
> > Sounds like we should fix udev ebuild and some ebuilds installing
> > udev rules to not use /$(get_libdir)/udev, but plain /lib/udev.
> > 
> > I used that in believe that /lib is identical or links
> > to /$(get_libdir) and multilib-strict requires it, but it seems to be
> > intelligent enough to only deny 64-bit libs to go to /lib.
> > 
> > So proper udev should use /lib/udev, correct?
> 
> Do you really think it'd be fine for some systems to possibly
> have /lib64 and /lib with random different contents?

Regarding /lib64/udev vs. /lib/udev: I think it is fine for some time.
Having some rules only in /lib64/udev when udevd looks info /lib/udev will 
make only these things break that depend on the extra rules.

The main question is: How many systems are affected by this /lib64 is not the 
same as /lib ?

Matthias

Re: [gentoo-dev] Re: rfc: libexec directory inconsistency

[Samuli Suominen]

On 04/24/2011 10:43 PM, Matthias Schwarzott wrote:
> Getting that discussion back on top.
>> Which is wrong, it should be /lib/foo instead, not $(get_libdir), to
>> follow what udev and other software in Linux has been using for a very
>> long time now.
> 
> Sounds like we should fix udev ebuild and some ebuilds installing udev rules to 
> not use /$(get_libdir)/udev, but plain /lib/udev.

Right, doesn't make sense to have both 32bit and 64bit ELF's for udev,
so we should stick with /lib/udev.

> 
> I used that in believe that /lib is identical or links to /$(get_libdir) and 
> multilib-strict requires it, but it seems to be intelligent enough to only 
> deny 64-bit libs to go to /lib.
> 
> So proper udev should use /lib/udev, correct?

Correct.



The udev situation is really a mess tree-wide, we have ebuilds
installing into 3 different directories now:

/etc/udev              (where user puts his local rules)
/$(get_libdir)/udev    (as explained above)
/lib/udev              (the correct one)

Check the Portage to see the sad status of inconsistency:

$ grep -r 'etc.*udev' */*/*.ebuild
$ grep -r 'get_libdir.*udev' */*/*.ebuild

Re: [gentoo-dev] Re: rfc: libexec directory inconsistency

[Matthias Schwarzott]

On Sonntag, 24. April 2011, Samuli Suominen wrote:
> On 04/24/2011 10:43 PM, Matthias Schwarzott wrote:
> > Getting that discussion back on top.
> > 
> >> Which is wrong, it should be /lib/foo instead, not $(get_libdir), to
> >> follow what udev and other software in Linux has been using for a very
> >> long time now.
> > 
> > Sounds like we should fix udev ebuild and some ebuilds installing udev
> > rules to not use /$(get_libdir)/udev, but plain /lib/udev.
> 
> Right, doesn't make sense to have both 32bit and 64bit ELF's for udev,
> so we should stick with /lib/udev.
> 
> > I used that in believe that /lib is identical or links to /$(get_libdir)
> > and multilib-strict requires it, but it seems to be intelligent enough
> > to only deny 64-bit libs to go to /lib.
> > 
> > So proper udev should use /lib/udev, correct?
> 
> Correct.
> 
> 
> 
> The udev situation is really a mess tree-wide, we have ebuilds
> installing into 3 different directories now:
> 
> /etc/udev              (where user puts his local rules)
> /$(get_libdir)/udev    (as explained above)
> /lib/udev              (the correct one)
> 
> Check the Portage to see the sad status of inconsistency:
> 
> $ grep -r 'etc.*udev' */*/*.ebuild
> $ grep -r 'get_libdir.*udev' */*/*.ebuild

And this does not even catch the cases where Makefiles (eventuelly together 
with configure-parameters) install to any of these three locations.

By the way, the bug that led me to think about the install location is this 
Bug #363549

Matthias

[gentoo-dev] Re: udev installs now to /lib/udev (was: rfc: libexec directory inconsistency)

[Matthias Schwarzott]

On Sonntag, 24. April 2011, Matthias Schwarzott wrote:
> Getting that discussion back on top.
> 
> On Samstag, 22. Januar 2011, Diego Elio Pettenò wrote:
> > Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto:
> > > Is there a reason for this? If not, would it break things if we start
> > > using /libexec as well as /usr/libexec?
> > 
> > More or less and yes, it would create one more root directory that has
> > no real usage to be there anyway...
> > 
> > > I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be
> > > $(get_libdir)/foo, which puts things in different directories
> > > depending on whether the system is multilib or not.
> > 
> > Which is wrong, it should be /lib/foo instead, not $(get_libdir), to
> > follow what udev and other software in Linux has been using for a very
> > long time now.
> 
> Sounds like we should fix udev ebuild and some ebuilds installing udev
> rules to not use /$(get_libdir)/udev, but plain /lib/udev.
> 
> I used that in believe that /lib is identical or links to /$(get_libdir)
> and multilib-strict requires it, but it seems to be intelligent enough to
> only deny 64-bit libs to go to /lib.
> 
> So proper udev should use /lib/udev, correct?
> 
sys-fs/udev-168 does now install to /lib/udev unconditionally.

Regards
Matthias

Re: [gentoo-dev] rfc: libexec directory inconsistency

[Mike Frysinger]

On Sat, Jan 22, 2011 at 12:02 PM, William Hubbs wrote:
> I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be
> $(get_libdir)/foo, which puts things in different directories depending on
> whether the system is multilib or not.
>
> I enquired from Robin why we do this, and I was told that libexec is
> supposed to contain things which are not abi specific, but we do not
> enforce that for /, even though we do for /usr.
>
> Is there a reason for this? If not, would it break things if we start
> using /libexec as well as /usr/libexec?

/libexec is also a horrible wart which we have avoided on purpose.
*BSD systems might use it, but we dont in Linux.

i dont think the multilib issue is terribly relevant unless the files
in question are used externally.  with dhcpcd and openerc, the files
are only used internally, so keeping them in the native multilib dir
isnt an issue.
-mike