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

[Allan McRae]

On 04/03/12 01:53, Dan McGee wrote:
> 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...


I have read all this multiple times and I have no idea whether you
actually object to the proposal or not...

I agree that /usr/lib/modules is just as crap as /lib/modules.  But
moving them to /usr does not make that situation worse, and it achieves
what I want to achieve with this move - getting all static content into
a single root directory.

If you want additional changes beyond the /usr move, I suggest preparing
another proposal to do so.  I find this a bit like suggesting we should
not have release pacman with signing support because hooks are not
implemented.  I do not like seeing progress on one issue being blocked
because of an independent issue with no real plan that can be handled
independently.

Allan