On Monday, 12. September 2011 13:39:59 Michael Mol wrote: > On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <a...@muc.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:
> >> 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. Exactly. > 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. I seem to have missed that part. > 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. Sounds reasonable. > 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. ack. > 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) Sounds good. > 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. Maybe a combination of the two? If dhcpd fails in your example, put it in the retry queue. After some failing attempts, remove it from there and log the error. BTW: if there are too many Michaels/Mikes on the list, call me "grimlog". I am used to that nick and feel strange if someone calls me "Schreckenbauer" :) Best, Michael, aka grimlog
