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

[Tom Gundersen]

Not sure exactly where the serious stuff ended and the trolling began,
so I'll take all of it seriously.

On Sat, Mar 3, 2012 at 3:28 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> bin/sbin/libraries, I agree with (besides perhaps shells that have
> been hardcoded for eternity, but links/symlinks will solve that).

Cool.

> Why on earth do the linker, kernel modules, etc. need to
> be in /usr/lib/ at all

See below.

> other than Poettering's raves and rants?

Seriously?

> 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.

Why not keep the linker with the other .so's? Why create new top-level
dirs? These three symlinks means that /lib must be a proper dir, why
stop it from being a symlink, and reduce compat with other distros
(once some, but not all, start moving udev rules and the like from
/lib to /usr/lib)?

Of course, you know all that, I should not fall for your trolling.

> 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.

Maybe I should have been clearer in the justification for moving
non-libs from /lib to /usr/lib.

The subdirs of /lib are (at least):

device-mapper
depmod.d
initcpio
modprobe.d
security
systemd
udev
firmware
modules

Littering / with non-standard dirs "just because" is obviously not
going to happen, so they either stay put, or move to /usr/lib. Based
on current practices, I think they all belong there. Do you have any
strong arguments to the contrary?

Lastly, as I mentioned before, I think having all of the static stuff
under /usr, is a lot cleaner than our current layout (and in the
future it might allow cool uses such as shared /usr among virtual
machines, hosts, chroots, whatever).

The firmware and modules dir might need some planning to get right,
but this was meant to be about the principle, rather than the
implementation, so I won't comment on that.

Cheers,

Tom