[arch-dev-public] [RFC] merge /bin, /sbin, /lib into /usr/bin and /usr/lib

Allan McRae allan at archlinux.org
Fri Mar 2 22:21:14 EST 2012


On 03/03/12 12:28, Dan McGee wrote:
> On Fri, Mar 2, 2012 at 7:53 PM, Tom Gundersen <teg at jklm.no> wrote:
>> /lib:
>>
>> There are also other things in /lib, I propose that
>> we temporarily patch udev, kmod and the few other packages to support
>> both /usr/lib and /lib (similarly to how systemd already works) so
>> things like udev rules and modprobe files can be moved over one
>> package at a time. Once all of this has moved, the last package to be
>> updated would be glibc that would move the linker and symlink /lib to
>> /usr/lib to maintain compat. We could then remove any transition
>> patches from udev++. For e this is sort of a no-brainer, with no real
>> risks or downsides.
>>
>> Thougts?
> 
> bin/sbin/libraries, I agree with (besides perhaps shells that have
> been hardcoded for eternity, but links/symlinks will solve that).
> 
> This bit I've quoted, I see absolutely no reason what so ever to screw
> around with. Why on earth do the linker, kernel modules, etc. need to
> be in /usr/lib/ at all, other than Poettering's raves and rants? 

I'll just point out that Poettering actually had nothing to do with the
any proposal to do this.  He just said the idea made sense.  So we can
not blame him for this one!

> Hell,
> if this whole thing is supposed to "make things less confusing" and we
> have to move them anyway, then:
> 
> * /lib/modules -> /kernel/modules
> * /lib/ld-2.15.so -> /linker/x86_64
> * /lib/ld-linux.so.2 -> /linker/i386
> 
> Of course I'm (probably) joking here. But my point is, moving these
> things to /usr is only going to be a pain in the ass, and I see
> absolutely no gain whatsoever from the argument your presented for
> doing this in the first place.

When I first looked at hurd and saw "usr -> .", I was immediately
convinced that this was a great idea.  It is simplifying the filesystem
layout in terms of where of where to look to find specific files (e.g.
is the library in /lib or /usr/lib) and makes packaging simpler (e.g. if
libfoo.so is in /lib and libfoo.a is in /usr/lib then you need symlinks
to libfoo.so in /usr/lib too).  It makes little difference from a users
perspective provided the symlink is present so the old directory layout
can be used transparently.

What convinced me of putting all this in /usr rather than on / is that I
can have a separate /usr partition that is mounted read only (unless I
want to do an update).  If everything from /usr gets moved to the root
(a.k.a hurd style) this would require many partitions.  (There is
apparently also benefits in allowing /usr to be shared across multiple
systems, but I do not care about such a setup and I am really not sure
this would work at all with Arch.)

So I am very much for this move as it is in the category of things that
make sense to me.  I also agree with the plan of dealing with /lib first
and then looking at /bin and /sbin.

Allan


More information about the arch-dev-public mailing list