On Thu, 8 Sep 2011 21:29:40 +0000 Alan Mackenzie <a...@muc.de> wrote:
> Hi, all. > > Forgive me butting in at a random place in this rather heated thread, > but .... > > On Thu, Sep 08, 2011 at 10:43:29PM +0200, Michael Schreckenbauer > 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 > > Would it not be possible to have a minimal /usr tree in the root > partition for udev's use at boot time, and to later mount a more > robust /usr partition over this? What am I missing here? A big problem will be that the package manager cannot easily maintain that "phase 1" code as it's under another mount point. Doing so would require the package manager to bind-mount / somewhere and copy updated binaries of essential packages there as well as into the real /usr. Not an insurmountable problem, it just requires changes to all affected packages, and well within the capabilities of distros. As a workaround, it's certainly a fine example. But I suspect it will annoy a lot of users and support people due to this "hidden" code being on the filesystem. If I were a package maintainer, I know I'd feel a little annoyed with having to track yet another trait in my packages. -- Alan McKinnnon alan.mckin...@gmail.com
