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
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
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
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 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 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
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.
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)