On Thu, Sep 8, 2011 at 5:11 PM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > 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.
This is the problem with people not seeing the big picture: Imagine a modern system with a bluetooth keyboard. I know, we are geeks, we use real-men keyboards, not connected with bluetooth. But believe me, there are people doing that, attaching bluetooth keyboards to their systems. And then, the system does a fsck, and it fails and the user needs to enter her password to go into maintenance mode. But guess what, if the bluetoothd daemon is not running, she is going to be a very very very sad user, because "it will throw an error and continue", leaving her unable to fix it. We are no longer in 1982: we actually have bluetooth keyboards. It is a very valid and very actual (probably more in the future) use case. To solve this case the devs had to choose between putting everything and the kitchen sink into /sbin or /bin (it is not bounded: anything can be executed from udev), or to ask to put /usr into / or using an initramfs. Sorry if I concur with the later option. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
