On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long
> 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.
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
> 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. 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.
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.