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

[Steven J Long]

Rich Freeman wrote:

> On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote:
>> That might be true for some Linux-only packages, but I really find it
>> hard to believe that any upstream targetting more than one OS (just
>> adding a BSD is enough) with software that could be considered critical
>> (I for one would include all POSIX utilities as well as basic stuff like
>> mount, fsck and lvm2) would want to ignore this kind of thing; if the
>> build-system is ignoring configuration, it's a bug.
>
> The issue is that if udev requires libfoo, then libfoo must not be in
> /usr.  If libfoo is libx11 or dbus or some other complex library, that
> will pull in a bunch of other stuff as well.  However, I doubt that
> the maintainers of all those libraries would consider them
> boot-essential, so they may not be inclined to make the move.
>
> Obviously we're not there now, but it is a possible consequence of
> moving in this direction.
>
Sure, but I'm curious: how would you set up an initramfs under those 
conditions?

Where I'm going with this, is that in both cases (an initramfs or a 
traditional rootfs system) we need to be aware of what libs pull in what.
Given that, there is actually common work both sides need.

If we could focus on that, we'd all actually be cooperating to fix things 
for both setups, instead of arguing about which is best. :)

> Keep in mind that systemd in particular does not aim to be
> cross-platform - they advertise this as one of their core features.
> Since tight integration is their goal that could slowly bring in a lot
> of other stuff.  The main platform pushing it along is Fedora, and
> they're aiming to move everything into /usr, so this is a non-issue
> for them.
>
I have a feeling that "integration" is being used as an excuse to avoid 
thinking about coupling and cohesion.

>> I read the decision from the Council to be "we will continue to support
>> the traditional split /usr eg with lvm, and no initramfs" and a Council
>> member put himself forward to maintain patches to udev to ensure that
>> going forward, since it is needed in his employment.
>>
>> Given that we can do it with initscripts, and don't need to fork udev at
>> all, what's the problem?
>
> I can't really comment on what the decision from the Council actually
> was.

Well, I've stated that several times now, and included the snippet from the 
log where Betelgeuse specifically asked Chainsaw to clarify that a 
"universal" minimal initramfs was not good enough, which was confirmed.

If Council members disagree with that interpretation, I'd welcome their 
clarification.

Split /usr with lvm was specifically discussed as a use-case, since it has 
been outlined in Gentoo documentation.

> However, maintaining patches to udev is effectively the same
> thing as forking it.  Right now it probably isn't hard, and over time
> that could change.
>
> The only time patches != fork is if the patches have been submitted
> upstream and are likely to be merged.
>
udev != openrc or any other init system, which is what we are patching[1] so 
that udev is not started til after localmount, should the user set a 
currently unsupported udev.conf option (initramfs="no").

We're only making minor shell-script modifications to udev and udev-mount 
initscripts, not openrc itself.

Earlymounts[2] is simply an additional initscript.

IOW no patches to udev whatsoever, so no fork.

> In any case, it isn't a crisis now and waiting a little to see which
> way the wind ends up blowing probably makes sense.
>
No indeed: those of us who wish to stay with our traditional setup, who have 
already configured our machines to localmount with built-in modules, can use 
the patched initscripts/earlymounts. What we'd like is for those, or 
equivalent functionality, to be maintained within Gentoo so we don't have to 
tweak patches whenever udev-init-scripts is updated, or in the earlymounts 
case there appear to be more issues, and those could use input from devs 
imo.

I prefer the patched approach, even if it is a bit more setup and I am 
biased, since it appears to have less potential for interaction with other 
stuff: if you never needed an initramfs before, and can localmount with just 
kernel-created device-nodes (eg: you need to change fstab from using 
/dev/vg/lv to /dev/mapper/vg-lv for lvm), then you're fine.

[1] http://forums.gentoo.org/viewtopic-t-901206.html
[2] http://forums.gentoo.org/viewtopic-t-918466.html
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)