On Sat, Mar 3, 2012 at 4:53 PM, Dan McGee <dpmcgee@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