On Sat, Mar 3, 2012 at 5:07 AM, Tom Gundersen <teg@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@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