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

[Steven J Long]

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.
>
"Making sure that partitions are mounted before udev starts" is a lot less 
of an ask than setting up an initramfs, and changing the way we've worked 
for years. It's what you proposed: an earlymounts init script, or patches to 
Gentoo initscripts to do the same thing. Neither involves any patches to 
udev proper, so no fork needs to be maintained.
 
>> 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.

Well I for one wouldn't like that, so no argument there: it's only for where 
the package would be definitely be considered for inclusion in a rescue-
disk/ initramfs/ partition, like say lvm2, mount or fsck. While you might 
not always be able to access the manpages, a system admin would want at 
least the binaries available.

I think it was mgorny who posted a check, which is why I brought it up. 
Perhaps an opt-in check if some variable is set, would be better? That way, 
only a maintainer who wants to mark the package as system-critical, and is 
happy to deal with linkage issues for binaries (including just deciding that 
some aren't so critical, which implies an optional exclusion variable, or 
listing binaries that should be checked) would set it, in the interests of 
overall portability and helping traditional users.

If a maintainer isn't interested, or upstream don't like it (ie won't accept 
bugs with such a setup even when linkage is not the issue), there's no 
additional burden.

Of course, if no developer thinks it's worth doing, the discussion is moot. 
It would seem at the least useful, if not necessary, however, if Gentoo is 
going to continue to support the traditional split /usr setup.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)