| 1 |
On Tue, Apr 10, 2012 at 09:09:03PM -0700, Zac Medico wrote: |
| 2 |
> On 04/10/2012 07:28 PM, Steven J Long wrote: |
| 3 |
> > I suppose you could script that, but again, it just seems like a lot of |
| 4 |
> > bother to implement an "alternative" that doesn't actually gain anything |
| 5 |
> > over the traditional setup (plus making sure that partitions are mounted |
| 6 |
> > before udev starts.) |
| 7 |
> |
| 8 |
> At least in the case of udev, we gain from not having to maintain a fork. |
| 9 |
> |
| 10 |
> > As for the burden of ensuring that binaries installed to /{s,}bin don't link |
| 11 |
> > to libs in /usr, why not just automate a QA check for that, and let |
| 12 |
> > developers decide whether a fix is necessary? After all, core packages that |
| 13 |
> > do that even when configured with prefix and execprefix = /, aren't so |
| 14 |
> > portable, and Gentoo has always championed "doing the right thing" wrt |
| 15 |
> > helping upstream fix portability issues. |
| 16 |
> |
| 17 |
> If the relevant ebuild developers really want to support that, it's fine |
| 18 |
> I guess. Hopefully that won't involve using static links as workarounds |
| 19 |
> for cross-/usr dependencies. |
| 20 |
|
| 21 |
Another issue to consider is binaries that want to access things in |
| 22 |
/usr/share/*. If a binary in /{bin,sbin} needs to access something in |
| 23 |
/usr/share/*, you have two choices. move the binary to /usr or move the |
| 24 |
thing it wants to access to / somewhere which would involve creating |
| 25 |
/share. Actually there is another choice, but I don't want to go there. |
| 26 |
That would be writing patches. |
| 27 |
|
| 28 |
The best way to solve all cross / - /usr dependencies imo is the /usr |
| 29 |
merge (moving everything from /{bin,sbin,lib*} to the counterparts in |
| 30 |
/usr), which has been discussed pretty extensively on this list, and |
| 31 |
there hasn't been a lot of opposition to it. |
| 32 |
|
| 33 |
William |
Archives