Re: [gentoo-user] udev + /usr

[Michael Mol]

On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <acm@×××.de> wrote:
> On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote:
>> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote:
>
>> > Hope nobody minds me starting a new thread with an accurate name.
>
>> > Which version of udev is it that has this nauseating feature of needing
>> > /usr loaded to boot?
>
>> > Somewhere in that version's source will be several (or lots of) "/usr".
>> > Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>> > throughout the source?
>
>> you misunderstood something. udev is able to run arbitrary scripts. Some of
>> those scripts are located in /usr/* or need something there. I doubt you will
>> find references to /usr in the udev-sources.
>
> Well, I'm a hacker.  udev is free source, therefore fair game.  I don't
> intend to put up with this nonsense without a fight.  As far as I can
> make out, this is just one guy, Kay Sievers, who's on a power trip.  Are
> there any indications at all that he actually talked to anybody in the
> wide world before making such a far reaching decision?

udev has always been able to run arbitrary scripts. The trouble is
that the arbitrary scripts other packages provide sometimes call for
things under /usr.

If I've read messages over the last couple days correctly, I think the
recent change is that some stuff udev *directly* depends on, as part
of the udev package itself, is being moved into /usr.

My best guess is that this allows udev to force the issue; it gets
blamed for other packages not loading correctly (when those other
packages put things in places which may or may not be available yet),
so the udev developer chose to force systems to have all of /usr
available before udev is run.

The first step in a clean solution, IMO, is to revert that change. The
second step is to fix the 'silent failure' problem for packages which
depend on /usr before /usr is available.

You might do it with a dependency tree which would control the order
things are done, but some packages may not be able to know what they
depend on. (take dhcpd, for example; it doesn't know what kind of
weird magic someone else put in exit-hooks)

Another solution would be to have a retry queue like what
Schreckenbauer (sorry; too many Mikes) was suggesting. It might be
difficult to discern a rulescript failure that stems from another rule
needing to be run first versus a rulescript failure that stems from,
e.g. a syntax error.

-- 
:wq