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

[Tom Gundersen]

On Sat, Mar 3, 2012 at 4:53 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> 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..."

In isolation many of the dirs under /lib do not make sense to move to
/usr/lib, but if we move them all together then, /usr/lib/modules is
better than /lib/modules because:

 * it increases cross-distro compatibility (due to the possibility of
/lib being a symlink, which otherwise would not be possible)
 * it simplifies the filesystem layout (all the static stuff going under /usr)
 * it allows us to get rid of /lib as a directory, making sure that
stuff will not "leak" back out of /usr over time
 * it does not make sense to have both /lib and /usr/lib if we can
avoid it, we should pick one

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

It seems that your argument has nothing to do with /usr v /, but more
with */lib v <something else>. You have several valid points, but the
way I see it is that we don't have the resources to diverge
significantly from all our upstreams. Hence, the only choice we have
is between /lib and /usr/lib (unless upstream can be convinced
otherwise).

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

For this to happen, the first step would be to convince the kmod and
udev maintainers. My impression is that the attitude is that /usr
should contain everything that is the sole domain of the package
manager. So you probably will have to convince people that this does
not include the kernel.

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

Same as above (but here only udev to convince). Maybe
/usr/share/firmware would be an easier sell.

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

Having configuration files in /run/<pkgname>, /etc/<pkgname> and
/usr/lib/<pkgname> is getting relatively widespread. Personally, I
think this design is very useful, though I don't know (care) why
/usr/lib was chosen over some other dir in /usr. Whatever happens,
let's make sure we keep consistency between apps and between distros
(so to change this would be very hard indeed).

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

Great :-)

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

I was thinking of your proposal of introducing /kernel and /linker.
One dir is not to bad, and /lib is not nonstandard, so that's not what
I had in mind at all.

> My point was, I just
> don't see how having kernel modules, firmware, etc. in /usr/lib makes
> any sense whatsoever.

The point is to get rid of the separation of /usr/lib and /lib. The
most obvious way to do this is to merge them, not to spread the
contents into other destinations.

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

Nothing is off limits. I was just stating that I am aware of the
issue, but chose not to comment on it yet (to keep the discussion on
track).

I certainly don't want to appear to rush into anything. My
"contributions welcome" comment should be seen in the context of the
wiki. It is clearly stated that some things are ready to be worked on
(the libs stuff we all agree on), some are not ready yet, and others
need further discussion (/lib/modules) .

Cheers,

Tom