Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[William Hubbs <williamh@gentoo.org>]

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

On Tue, Apr 10, 2012 at 09:09:03PM -0700, Zac Medico wrote:
> On 04/10/2012 07:28 PM, Steven J Long wrote:
> > I suppose you could script that, but again, it just seems like a lot of
> > bother to implement an "alternative" that doesn't actually gain anything
> > over the traditional setup (plus making sure that partitions are mounted
> > before udev starts.)
> 
> At least in the case of udev, we gain from not having to maintain a fork.
> 
> > As for the burden of ensuring that binaries installed to /{s,}bin don't link
> > to libs in /usr, why not just automate a QA check for that, and let
> > developers decide whether a fix is necessary? After all, core packages that
> > do that even when configured with prefix and execprefix = /, aren't so
> > portable, and Gentoo has always championed "doing the right thing" wrt
> > helping upstream fix portability issues.
> 
> If the relevant ebuild developers really want to support that, it's fine 
> I guess. Hopefully that won't involve using static links as workarounds 
> for cross-/usr dependencies.

Another issue to consider is binaries that want to access things in
/usr/share/*. If a binary in /{bin,sbin} needs to access something in
/usr/share/*, you have two choices. move the binary to /usr or move the
thing it wants to access to / somewhere which would involve creating
/share. Actually there is another choice, but I don't want to go there.
That would be writing patches.

The best way to solve all cross / - /usr dependencies imo is the /usr
merge (moving everything from /{bin,sbin,lib*} to the counterparts in
/usr), which has been discussed pretty extensively on this list, and
there hasn't been a lot of opposition to it.

William


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