Re: no deprecation of /usr as a standalone filesystem
On Sun, May 31, 2009 at 7:43 PM, Marco d'Itri <md@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.langhoff@gmail.com
martin@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
Reply to: