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

[Dan McGee]

On Sat, Mar 3, 2012 at 5:07 AM, Tom Gundersen <teg at jklm.no> wrote:
> Not sure exactly where the serious stuff ended and the trolling began,
> so I'll take all of it seriously.
I was the first reply. None of this was trolling, it was legitimate gripes.

> 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.
Please tell me exactly what I'm looking for, becuase I couldn't find
it. I read through your first email, and not once was the following
statement made:
    "lib/modules is better than /lib/modules because..."

>> 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)?

Fine, take the linker and move it to /usr/lib (Doesn't this require
patching the kernel?). But that wasn't the point of my typing here,
and you seemed to get stuck on that.

But you can truely tell me, with a straight face, the following things
belong in /usr/lib, let alone /lib? My whole point of this "troll" was
to point out we're spending time and pain moving from bad location A
to bad location B- shouldn't we just take a step back, stop following
Fedora blindly, and point out that some of this makes no sense at all?

* Kernel modules- these are "libraries" only in the strictest sense,
but even systesm sharing a common /usr have no need to share kernel
modules (or might be able to, if they are booting from different
kernels). So, proposed location- /kernel/modules.
* Kernel firmware- architecture agnostic. Most of this doesn't belong
in a library directory as it isn't executable code per se by the OS
itself; it is also architecture agnostic. Proposed location-
/kernel/firmware.
* Udev rules- once again, this is architecture agnostic, not
executable, etc. Why is this in lib?
* /lib/depmod.d/search.conf is owned by kmod 5-4- WTF is this, besides
a funny joke? Configuration in /lib?
* /lib/device-mapper/, /lib/multipath/, /lib/security/- no problems at
all with moving, this is exactly the type of move I do agree with, as
it is a logical separation that makes no sense.

> 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?
See above.

> 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).
/lib is one directory, as is /usr. That honestly doesn't seem like all
that much of a hassle to me. Ideal? No. But I'm not sure where the
"littering" of non-standard dirs in '/' comes into place.

Am I completely serious about the creation of a new /kernel directory?
Not really, especially as there seems to be an allergy toward
top-level directory creation (unless their name is /run). But hell,
throw it in /boot then! No new directory created. My point was, I just
don't see how having kernel modules, firmware, etc. in /usr/lib makes
any sense whatsoever.

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

Well when you're telling people in a follow-up email "Contributions
welcome. Especially in the form of rebuilds ;-)", somehow I felt like
commenting on the implementation wasn't off-limits...

-Dan