Not sure exactly where the serious stuff ended and the trolling began, so I'll take all of it seriously. 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.
other than Poettering's raves and rants?
Seriously?
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)? 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? 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). 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. Cheers, Tom