On Sun, May 31, 2009 at 7:43 PM, Marco d'Itri <m...@linux.it> wrote: > This is a summary of last month's thread about the feasibility of > removing support for /usr on a standalone filesystem. > > The issue was raised by the udev upstream maintainer along with the udev > package maintainers of the major distributions, who all agreed that this > configuration is not supported. > > This is relevant for udev becase kernel events can trigger the > execution of programs at the very beginning of the boot when only the > root is mounted.
That udev-triggered executables must not reside in /usr makes sense. And it makes sense to state that executables triggered from udev must be relatively low in the stack. Do I understand this right? The concern is about NetworkManager and similar stuff? IMHO the right fix is to decouple the bits of NM that receive the udev event from the high-in-the-stack, late-starting, a-zillion-deps NetworkManager. A small executable can catch the events and store them if the rest of the system is not there. IIRC, NM uses dbus which is also fairly late and laden. A simpler scheme would work. I don't meant to pick on NM, but it's a fairly well-known example that takes us from a udev event all the way to a desktop applet. Disk insertion applies too. My take is that software for the desktop that is mature and high quality must be extra careful in what it puts in udev scripts -- minimal deps and de-coupled operation from the desktop is a must. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org