| 1 |
Getting that discussion back on top. |
| 2 |
|
| 3 |
On Samstag, 22. Januar 2011, Diego Elio Pettenò wrote: |
| 4 |
> Il giorno sab, 22/01/2011 alle 11.02 -0600, William Hubbs ha scritto: |
| 5 |
> > Is there a reason for this? If not, would it break things if we start |
| 6 |
> > using /libexec as well as /usr/libexec? |
| 7 |
> |
| 8 |
> More or less and yes, it would create one more root directory that has |
| 9 |
> no real usage to be there anyway... |
| 10 |
> |
| 11 |
> > I noticed that for dhcpcd and openrc we force their LIBEXECDIR to be |
| 12 |
> > $(get_libdir)/foo, which puts things in different directories |
| 13 |
> > depending on whether the system is multilib or not. |
| 14 |
> |
| 15 |
> Which is wrong, it should be /lib/foo instead, not $(get_libdir), to |
| 16 |
> follow what udev and other software in Linux has been using for a very |
| 17 |
> long time now. |
| 18 |
|
| 19 |
Sounds like we should fix udev ebuild and some ebuilds installing udev rules to |
| 20 |
not use /$(get_libdir)/udev, but plain /lib/udev. |
| 21 |
|
| 22 |
I used that in believe that /lib is identical or links to /$(get_libdir) and |
| 23 |
multilib-strict requires it, but it seems to be intelligent enough to only |
| 24 |
deny 64-bit libs to go to /lib. |
| 25 |
|
| 26 |
So proper udev should use /lib/udev, correct? |
| 27 |
|
| 28 |
Matthias |
Archives