On Thu, 8 Sep 2011 16:48:45 -0400 Canek Peláez Valdés <can...@gmail.com> wrote:
> On Thu, Sep 8, 2011 at 4:43 PM, Michael Schreckenbauer > <grim...@gmx.de> wrote: > > Am Donnerstag, 8. September 2011, 16:23:36 schrieb Canek Peláez > > Valdés: > >> > In what valid way does access to /usr become something that udev > >> > may be required to support? > >> > >> It is a matter of what else do you end having in /bin and /lib. > >> Remember that udev rules can execute arbitrary code. Do all that > >> code needs to be moved to /bin and /lib also? > > > > Of course. That's what /bin, /sbin and /lib are for. > > > >> I keep telling: it is a difficult problem. > > > > No. Just move or copy the binaries and libs *you* use for *your* > > udev-scripts to /bin, /sbin and /lib > > I *really* don't think bluetoothd belongs to /sbin. But, hey, that's > me. Then do what all sane code does when the scripts it uses fails or cannot be found - throw an error and continue. Direct the distros to design their systems such that code for essential functionality is guaranteed to always be available, / is a fine way to do this. Everything else and especially functions that the system can tolerate not having, goes wherever the distro feels like having it. The distro (or user) can then decide what to do and decide what is and isn't essential, without having to rig things so that the system's entire codebase is always on-line. It certainly isn't the udev maintainer's fault if the distro puts code required to use SATA in a place that cannot be found. That's a distro bug. -- Alan McKinnnon alan.mckin...@gmail.com
