Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
On Sun, 24 Apr 2011 22:38:13 +0200 Matthias Schwarzott z...@gentoo.org wrote: On Sonntag, 24. April 2011, Michał Górny wrote: On Sun, 24 Apr 2011 21:43:16 +0200 Matthias Schwarzott z...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
On Sonntag, 24. April 2011, Michał Górny wrote: On Sun, 24 Apr 2011 21:43:16 +0200 Matthias Schwarzott z...@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
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
On Sun, 24 Apr 2011 21:43:16 +0200 Matthias Schwarzott z...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
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
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
Re: [gentoo-dev] Re: rfc: libexec directory inconsistency
On Sonntag, 24. April 2011, Michał Górny wrote: On Sun, 24 Apr 2011 21:43:16 +0200 Matthias Schwarzott z...@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
[gentoo-dev] Re: rfc: libexec directory inconsistency
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/
