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

newer
[arch-dev-public] Signoff report...

older
[arch-dev-public] ghc 7.4.1 moved...

Tom Gundersen

3 Mar 2012 3 Mar '12

1:53 a.m.

Hi guys, Some of us have been discussing the feasibility of merging /bin, /sbin and /lib with their /usr counterparts. It seems that this is doable and a few of us have been testing it locally. However, before doing any more work on this I thought it would make sense to make an official proposal to find out if this is something people would be happy with, at least in principle. If so, we could get back to a more concrete proposal once the details have been worked out. I assume that most people are familiar with the general idea and why we would want to do this, but just in case I'll outline my point of view: * Traditionally we have kept all our binaries and libraries in /usr. The exception were the things needed during early boot before /usr was mounted (assuming it was on a separate partition, if not there was never any need for this at all). * We now mount /usr from the initramfs, so there is no longer any need to keep any binaries or libraries on the rootfs. * Having four different locations for binaries ({/usr,}/{s,}bin}) and two locations for libraries ({/usr,}/lib) is less KISS than having one location for binaries /usr/bin and one for libraries /usr/lib. * By symlinking the old directories to /usr/{bin,lib} we keep backwards compatibility, and also improve our compatibility with distros that chose to put their binaries in different locations. * Several of the packages that have traditionally been outside of /usr, are being maintained by people who develop on systems where there is no longer a split. In the long term this means that more maintenance will be shifted towards us as we have to check and fix any assumptions that these devs might have made that don't apply to us (unless we also do the merge). * Two common objections: 1) why not move everything to /: that would mean littering the rootfs with lots of new dirs, for no gain. Having all of the static package files in one dir (/usr) seems much cleaner to me. 2) we should distinguish between bin and sbin: whenever people add features to a "superuser only tool" so that it becomes useful to a regular user, it means it should be moved from sbin to bin. However, in practice this does not happen due to the paths being hardcoded. Instead we just put both sbin and bin in everyone's PATH and the distinction is essentially meaningless. Implementation: /lib: For the libraries this can be done package-by-package, some have already been done. There are also other things in /lib, I propose that we temporarily patch udev, kmod and the few other packages to support both /usr/lib and /lib (similarly to how systemd already works) so things like udev rules and modprobe files can be moved over one package at a time. Once all of this has moved, the last package to be updated would be glibc that would move the linker and symlink /lib to /usr/lib to maintain compat. We could then remove any transition patches from udev++. For e this is sort of a no-brainer, with no real risks or downsides. /bin, /sbin: This is a bit more tricky, and would essentially require a rebuild of the ~90 relevant packages to move their contents to /usr/bin and move these packages together with a new filesystem package that symlinks /sbin and /bin to /usr/bin. I'm just giving a rough overview here, I don't think there is any need for getting bogged down in details until we have made our decision. /usr/sbin: I think there is no point in keeping this directory, and it should eventually also be merged with /usr/bin. However, there is no need to do this at the same time, so let's get back to this once we have some experience from the above moves. TL;DR: If you don't package stuff needed by early boot, this should not matter to you one bit (fingers crossed). Thougts? Tom

Show replies by date

Dan McGee

3 Mar 3 Mar

2:28 a.m.

On Fri, Mar 2, 2012 at 7:53 PM, Tom Gundersen wrote:

...

/lib:

There are also other things in /lib, I propose that we temporarily patch udev, kmod and the few other packages to support both /usr/lib and /lib (similarly to how systemd already works) so things like udev rules and modprobe files can be moved over one package at a time. Once all of this has moved, the last package to be updated would be glibc that would move the linker and symlink /lib to /usr/lib to maintain compat. We could then remove any transition patches from udev++. For e this is sort of a no-brainer, with no real risks or downsides.

Thougts?

bin/sbin/libraries, I agree with (besides perhaps shells that have been hardcoded for eternity, but links/symlinks will solve that). This bit I've quoted, I see absolutely no reason what so ever to screw around with. Why on earth do the linker, kernel modules, etc. need to be in /usr/lib/ at all, other than Poettering's raves and rants? 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. 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. -Dan

Jan Steffens

2:52 a.m.

On Sat, Mar 3, 2012 at 3:28 AM, Dan McGee wrote:

...

Why on earth do the linker, kernel modules, etc. need to be in /usr/lib/ at all, other than Poettering's raves and rants?

We need to empty /lib, otherwise we can't symlink it.

Dan McGee

3:08 a.m.

On Fri, Mar 2, 2012 at 8:52 PM, Jan Steffens wrote:

...

On Sat, Mar 3, 2012 at 3:28 AM, Dan McGee wrote:

...
Why on earth do the linker, kernel modules, etc. need to be in /usr/lib/ at all, other than Poettering's raves and rants?

We need to empty /lib, otherwise we can't symlink it.

I never said it should be symlinked at any point, ever. bin/sbin were a different story. -Dan

Thomas Bächler

5:53 p.m.

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

Am 03.03.2012 03:52, schrieb Jan Steffens:

...

On Sat, Mar 3, 2012 at 3:28 AM, Dan McGee wrote:

...
Why on earth do the linker, kernel modules, etc. need to be in /usr/lib/ at all, other than Poettering's raves and rants?

We need to empty /lib, otherwise we can't symlink it.

There is no need at all to ever symlink /lib! I would be fine with a /lib directory that has exactly 2 symlinks (namely ld-linux.so.2 and ld-linux-x86_64.so.2). Also stuff like kernel modules, udev rules, and so on. Why move them at all? The primary concern is binaries, that's where problems may occur (that's why we would - long-term - need symlinks from /bin, /sbin and /usr/sbin to /bin). For libraries, we can put them whereever we want.

Allan McRae

3:21 a.m.

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

On 03/03/12 12:28, Dan McGee wrote:

...

On Fri, Mar 2, 2012 at 7:53 PM, Tom Gundersen wrote:

...
/lib:

There are also other things in /lib, I propose that we temporarily patch udev, kmod and the few other packages to support both /usr/lib and /lib (similarly to how systemd already works) so things like udev rules and modprobe files can be moved over one package at a time. Once all of this has moved, the last package to be updated would be glibc that would move the linker and symlink /lib to /usr/lib to maintain compat. We could then remove any transition patches from udev++. For e this is sort of a no-brainer, with no real risks or downsides.

Thougts?

bin/sbin/libraries, I agree with (besides perhaps shells that have been hardcoded for eternity, but links/symlinks will solve that).

This bit I've quoted, I see absolutely no reason what so ever to screw around with. Why on earth do the linker, kernel modules, etc. need to be in /usr/lib/ at all, other than Poettering's raves and rants?

I'll just point out that Poettering actually had nothing to do with the any proposal to do this. He just said the idea made sense. So we can not blame him for this one!

...

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

When I first looked at hurd and saw "usr -> .", I was immediately convinced that this was a great idea. It is simplifying the filesystem layout in terms of where of where to look to find specific files (e.g. is the library in /lib or /usr/lib) and makes packaging simpler (e.g. if libfoo.so is in /lib and libfoo.a is in /usr/lib then you need symlinks to libfoo.so in /usr/lib too). It makes little difference from a users perspective provided the symlink is present so the old directory layout can be used transparently. What convinced me of putting all this in /usr rather than on / is that I can have a separate /usr partition that is mounted read only (unless I want to do an update). If everything from /usr gets moved to the root (a.k.a hurd style) this would require many partitions. (There is apparently also benefits in allowing /usr to be shared across multiple systems, but I do not care about such a setup and I am really not sure this would work at all with Arch.) So I am very much for this move as it is in the category of things that make sense to me. I also agree with the plan of dealing with /lib first and then looking at /bin and /sbin. Allan

Pierre Schmitz

9:49 a.m.

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

Am 03.03.2012 04:21, schrieb Allan McRae:

...

What convinced me of putting all this in /usr rather than on / is that I can have a separate /usr partition that is mounted read only (unless I want to do an update). If everything from /usr gets moved to the root (a.k.a hurd style) this would require many partitions. (There is apparently also benefits in allowing /usr to be shared across multiple systems, but I do not care about such a setup and I am really not sure this would work at all with Arch.)

I agree that the /usr subtree we have atm and also the distinction of bin and sbin is not really useful and confuses more than it helps. Especially the sbin one doesn't make any sense. So it's nice to cleanup our filesystem and merge things together. While I don't think a read-only /usr is of any use or even advisable I see that having everything in /usr is more flexible; so I am fine with that. So in short: +1 from me. -- Pierre Schmitz, http://pierre-schmitz.com

Rémy Oudompheng

9:53 a.m.

Le 3 mars 2012 10:49, Pierre Schmitz a écrit :

...

Am 03.03.2012 04:21, schrieb Allan McRae:

...
What convinced me of putting all this in /usr rather than on / is that I can have a separate /usr partition that is mounted read only (unless I want to do an update). If everything from /usr gets moved to the root (a.k.a hurd style) this would require many partitions. (There is apparently also benefits in allowing /usr to be shared across multiple systems, but I do not care about such a setup and I am really not sure this would work at all with Arch.)

I agree that the /usr subtree we have atm and also the distinction of bin and sbin is not really useful and confuses more than it helps. Especially the sbin one doesn't make any sense. So it's nice to cleanup our filesystem and merge things together. While I don't think a read-only /usr is of any use or even advisable I see that having everything in /usr is more flexible; so I am fine with that.

So in short: +1 from me.

Similar opinion. And as Dan said, please don't patch things, I'd prefer that we cleanup things first, and see what is left. Rémy.

Tom Gundersen

10:15 a.m.

On Sat, Mar 3, 2012 at 10:53 AM, Rémy Oudompheng wrote:

...

Le 3 mars 2012 10:49, Pierre Schmitz a écrit :

...
Am 03.03.2012 04:21, schrieb Allan McRae:

...
What convinced me of putting all this in /usr rather than on / is that I can have a separate /usr partition that is mounted read only (unless I want to do an update). If everything from /usr gets moved to the root (a.k.a hurd style) this would require many partitions. (There is apparently also benefits in allowing /usr to be shared across multiple systems, but I do not care about such a setup and I am really not sure this would work at all with Arch.)

I agree that the /usr subtree we have atm and also the distinction of bin and sbin is not really useful and confuses more than it helps. Especially the sbin one doesn't make any sense. So it's nice to cleanup our filesystem and merge things together. While I don't think a read-only /usr is of any use or even advisable I see that having everything in /usr is more flexible; so I am fine with that.

So in short: +1 from me.

Similar opinion. And as Dan said, please don't patch things, I'd prefer that we cleanup things first, and see what is left.

The patches I posted for namcap documents what would be left (the one related to /lib at least). It will throw warnings for the things we can move without patching (libraries and systemd unit files (assuming Dave will flip a needed config switch)), but will not complain about stuff that would require (one line!) patches (like the location of udev rules). The patching I mentioned would only be a transitional measure which would be reverted once the symlink is in place, it is really an implementation detail. Cheers, Tom

Andrea Scarpino

9:55 a.m.

On Saturday 03 March 2012 10:49:43 Pierre Schmitz wrote:

...

I agree that the /usr subtree we have atm and also the distinction of bin and sbin is not really useful and confuses more than it helps. Especially the sbin one doesn't make any sense. So it's nice to cleanup our filesystem and merge things together. While I don't think a read-only /usr is of any use or even advisable I see that having everything in /usr is more flexible; so I am fine with that.

So in short: +1 from me. Everything in /usr and to be able to mount it as read-only is nice IMHO. (and if I understood correctly I could even mount a /usr with KDE-git and one with KDE-from-extra).

Another +1 from me. -- Andrea

Tom Gundersen

3:33 p.m.

On Sat, Mar 3, 2012 at 4:21 AM, Allan McRae wrote:

...

So I am very much for this move as it is in the category of things that make sense to me. I also agree with the plan of dealing with /lib first and then looking at /bin and /sbin.

Allan and I started a wiki page. Contributions welcome. Especially in the form of rebuilds ;-) https://wiki.archlinux.org/index.php/DeveloperWiki:UsrMove Cheers, Tom

Tom Gundersen

11:07 a.m.

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

Dan McGee

3:53 p.m.

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

Tom Gundersen

5:24 p.m.

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

Ionut Biru

5:36 p.m.

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

On 03/03/2012 07:24 PM, Tom Gundersen wrote:

...

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

I'm against moving kernel modules in any other directory because is NOT improving cross-distro at all and mostly breaks every application that expects /lib/modules/`unamer -r`. Don't drop traditions and I'm ok with it. -- Ionuț

Tom Gundersen

5:49 p.m.

On Sat, Mar 3, 2012 at 6:36 PM, Ionut Biru wrote:

...

I'm against moving kernel modules in any other directory because is NOT improving cross-distro at all and mostly breaks every application that expects /lib/modules/`unamer -r`.

This is an important point: referencing /lib/modules/ will still work exactly as before, due to the symlink. Otherwise, this would have been crazy. -t

Allan McRae

10:33 p.m.

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

On 04/03/12 01:53, Dan McGee wrote:

...

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

Andreas Radke

9:13 a.m.

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

What about the FHS? Why should we do our own thing here again? The bad in end user Linux experience is the incompatibility brought by such non-standards. And has this idea anything to do with recent Fedora changes? IMHO we are now the next big community distro behind the commercial players and should raise our voice more often in projects that define future standards. -Andy

Allan McRae

9:49 a.m.

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

On 03/03/12 19:13, Andreas Radke wrote:

...

What about the FHS? Why should we do our own thing here again? The bad in end user Linux experience is the incompatibility brought by such non-standards.

This does not conflict with the FHS. e.g. the FHS only says /bin should exist and what files should be found there. There is nothing saying that /bin can not be a symlink to /usr/bin. This actually will result in more cross-distro compatibility as there will not longer be differences about where files are located. To pick an example, /bin/awk will exist and /usr/bin/awk will exist, so either hardcoded path will work. Note this currently happens for our gawk package with symlinks, but only after a bug report asking for us to put both paths sat in our bug tracker for years... Now the changes Debian are making is an entirely different story...

...

And has this idea anything to do with recent Fedora changes?

It most definitely is influenced by it. But those of us in favor of this are not just blindly following Fedora but actually think it is a good idea.

...

IMHO we are now the next big community distro behind the commercial players and should raise our voice more often in projects that define future standards.

Sure. Anybody can join the appropriate mailing lists and influence things like this. For example, python PEP-394 (http://www.python.org/dev/peps/pep-0394/) was essentially written due to Arch making python3 the default python. Allan

Pierre Schmitz

9:54 a.m.

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

Am 03.03.2012 10:49, schrieb Allan McRae:

...

This actually will result in more cross-distro compatibility as there will not longer be differences about where files are located.

Indeed. And also I don't see any great activity at the FHS project. It seems like they more or less just add directories that are used in the wild. So the FHS will probably have an entry for this. -- Pierre Schmitz, http://pierre-schmitz.com

Tom Gundersen

10:09 a.m.

On Sat, Mar 3, 2012 at 10:13 AM, Andreas Radke wrote:

...

What about the FHS? Why should we do our own thing here again? The bad in end user Linux experience is the incompatibility brought by such non-standards.

I absolutely agree that "doing our own thing" would need a strong justification. This change would not do that though, it would be in line with what the other major distro's are doing, and it would not be FHS incompatible.

...

And has this idea anything to do with recent Fedora changes?

In the sense that I read all the Fedora proposals and discussions (as well as the discussions of the other distros) and came to the conclusion that this was a very good idea, yes. However, following Fedora is not my motivation, and in fact I believe the way they implemented the transition is completely wrong. I should perhaps have linked to Fedora's plans to give proper credit for the idea, but I'm afraid that would quickly have derailed the discussion.

...

IMHO we are now the next big community distro behind the commercial players and should raise our voice more often in projects that define future standards.

We certainly should be critical, and take part in discussions. From my personal experience, going through committees are not the way to do it (certainly not the FHS). However, discussing personally with the people who push the changes and write the code is very productive (which several of us are doing). Cheers, Tom

Thomas Bächler

6:02 p.m.

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

Am 03.03.2012 10:13, schrieb Andreas Radke:

...

IMHO we are now the next big community distro behind the commercial players and should raise our voice more often in projects that define future standards.

Some of us are. One example is how Dave not only was an important force behind fixing bugs in recent kmod and util-linux releases, but he also influenced changes in behaviour in those projects to our advantage. It's up to the individual to influence things their way. For instance, although I do not know for sure, I assume that your involvement in Libreoffice discussions has lead to improvements in their build systems (btw, some libreoffice guys asked about you at FOSDEM in Brussels). There are more examples. They seem insignificant, but they're not.

4451

Age (days ago)

4451

Last active (days ago)

List overview

Download

21 comments

10 participants

participants (10)

Allan McRae
Andrea Scarpino
Andreas Radke
Dan McGee
Ionut Biru
Jan Steffens
Pierre Schmitz
Rémy Oudompheng
Thomas Bächler
Tom Gundersen