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