Merge /{s,}bin with /usr/{s,}bin

fallen_arches · 2012-08-30 22:09:12

With the recent /lib -> usr/lib move, and things like systemD on the horizion, is it time to merge /bin and /sbin with /usr? There was some talk in "GNU/Linux Discussion" then Fedora started down this path. What do people think about this idea today (2012-08-30)? I personally like the idea of a read-only /usr partition mounted by initrd that I could share between VM's. I'd also like to encrypt the partition, share it via NFS, take snapshots, and a few other fun activies.

I could probably do this today if I mapped /bin to usr/bin.root to sidestep /bin/foobar -> /usr/bin/foobar symlink issues. I think the hardest part would be getting mkinitcpio's initrd to decrypt / and /usr, and then mount /usr. I think all the pieces are there in one form or another today, I'd just need to string them togeather properly. As for the distro as a whole, would /bin & /sbin be very different from the /lib move?

Thank you for your input :)

fsckd · 2012-08-30 22:35:12

Mentioned here and on the mailing lists. No concrete plans publically disclosed yet since we're still in the middle of the transition to systemd.

Allan · 2012-08-30 22:36:19

Will require pacman-4.1 before this really gets done.

andjeng · 2012-08-31 03:51:02

i'm sorry allan. i just dont know why we should merge /sbin to /usr/sbin
i would very appreciate if you explain it to me.

karol · 2012-08-31 08:09:24

andjeng wrote:

i'm sorry allan. i just dont know why we should merge /sbin to /usr/sbin
i would very appreciate if you explain it to me.

https://mailman.archlinux.org/pipermail … 22625.html

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

89c51 · 2012-08-31 13:55:03

Allan wrote:

Will require pacman-4.1 before this really gets done.

And pacman-4.1 will be out in ..... (months)

inb4 when its ready

andjeng · 2012-08-31 16:07:37

karol wrote:

andjeng wrote:
i'm sorry allan. i just dont know why we should merge /sbin to /usr/sbin
i would very appreciate if you explain it to me.
https://mailman.archlinux.org/pipermail … 22625.html
* 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.

thankyou Karol.
explains _alot_ of things.

Jristz · 2012-09-01 06:16:54

and Why we need pacman 4.1 ????
I maybe a for to deal whith absense of binaries in any location???

yaffare · 2012-09-01 18:06:51

One thing im always asking myself, why did you choose to move everything in /usr and not the other way round?

Wouldnt it be more kiss, just to have the folders /bin /lib?

Why do we need /usr anyway? I know in the past /usr was ment to be on a separate partition and shared among different machines,
but is there still a use-case for this today?

fsckd · 2012-09-01 18:24:41

yaffare wrote:

Why do we need /usr anyway? I know in the past /usr was ment to be on a separate partition and shared among different machines,
but is there still a use-case for this today?

In the mailing list thread karol links to above. Follow along until you find Allan's post.

yaffare · 2012-09-01 18:49:10

thx fsckd

Allan wrote:

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.

Didnt know hurd was doing it, definitely like it better,
as the read only partition is a very good point, but how many actually use it? < 5% I guess,
besides someone could still do it as Allan said, he just needs like 3 partitions instead of 1.

Last edited by yaffare (2012-09-01 18:49:32)

ConnorBehan · 2012-09-02 20:09:37

I fully support this move of putting all binaries on an equal footing. I don't know how many times I've rolled my eyes about how arbitrary it is now. Avahi thinks it's more critical than grep? Please.

I also think it's more pragmatic to keep /usr.
1. This would create /share, /include and /src.
2. Changing "--prefix=/usr" to "--prefix=/" in every program would be a huge undertaking.
3. An impression I got in my early days with Arch was that a lot of people do have it on its own partition. And the one weakness of these plans to reorganize the filesystem is that you can't create cross-device symlinks. We wouldn't want to have to go with some kernel level hack like GoboLinux uses, would we?

Allan · 2012-09-02 22:27:35

ConnorBehan wrote:

And the one weakness of these plans to reorganize the filesystem is that you can't create cross-device symlinks.

symlinks are fine... hardlinks are not.

karol · 2012-09-08 10:38:02

A thread about the idea of symlinking /usr to / : https://bbs.archlinux.org/viewtopic.php?id=145942

techwiz · 2012-09-15 04:36:26

Just my 2 cents but I always thought /usr was meant to contain userspace binaries while the stuff in /bin and /lib were all system specific (read as "Don't mess with this stuff or kiss your system goodbye") so that the usr directory could in theory be isolated from the system preventing rogue apps from going haywire on the system. And of course sbin was for superuser binaries (I think it still is). I don't think any of this matters anymore since permissions are pretty much the same now between the 2 locations and root owns everything for the most part except the home directory.

tomegun · 2012-09-15 14:12:19

techwiz wrote:

Just my 2 cents but I always thought /usr was meant to contain userspace binaries while the stuff in /bin and /lib were all system specific (read as "Don't mess with this stuff or kiss your system goodbye") so that the usr directory could in theory be isolated from the system preventing rogue apps from going haywire on the system. And of course sbin was for superuser binaries (I think it still is). I don't think any of this matters anymore since permissions are pretty much the same now between the 2 locations and root owns everything for the most part except the home directory.

The history of /usr is long and amusing (originally it was what /home is now, then hack layered upon hack and a chain of reinterpretations of /usr's purpose gave us what we have today).

Anyway, the description you give is roughly what we used to have before we started merging stuff back from / to /usr. There are several problems:

* it is not really clear what is the important stuff and what is the user-specific stuff as things change over time and between different users/use-cases
* moving binaries from /usr/bin to /bin (or any other combination) without adding symlinks for compatibility is likely to cause problems as the path will be hardcoded in scripts++
* we end up with having stuff in /usr that should be in / and stuff in / that should be in /usr, either because we did not anticipate the change in usage and stuff is "stuck", or because we thought something might change in the future and took this into account, but it did not.
* the problem is even more pronounced with /bin v. /sbin, as adding a feature that can be used by non-root users to a binary that used to be only for root means that it should move to /bin. However, we can't do that (because the path is hardcoded everywhere). The end result is that both /bin and /sbin is in the PATH of everyone (including non-root), and the distinction is meaningless.
* if an app can change /usr then it can change /bin. There should never be a need for any app to have write-access to either.

In short: getting the distinction right is hard. Even if we could do it, it does not gain us anything.

-t

frony0 · 2013-04-01 10:42:54

Allan wrote:

Will require pacman-4.1 before this really gets done.

Can I hold you to that now? Is there any timescale for when this'll be done, now that pacman 4.1 has been completed?

Trilby · 2013-04-01 10:52:05

I'm sure you can hold him to that. Now it's a done deal: whenever the transition happens, pacman 4.1 will have been completed first. This is just as true if the /usr transition is done in 10 years as if it is done tomorrow.

Allan · 2013-04-01 10:55:01

I'd guess it will still be a few months...

Jristz · 2013-04-01 13:00:53

Allan wrote:

I'd guess it will still be a few months...

and why not begin whit the pollicy about placing all in bin now??

you can discover bugs on programs related to this more early and adressed with uptream early for prevent patching programs

Allan · 2013-04-01 13:09:22

Because it will screw less people over if we move everything and create the need symlinks in one go.

frony0 · 2013-04-01 14:37:39

Allan wrote:

I'd guess it will still be a few months...

Do you have an idea an idea of how you're going to do it?

e.g. https://wiki.archlinux.org/index.php/De … ki:UsrMove for the /lib move

Another wiki like that would be great if you could

progandy · 2013-04-01 18:53:53

Do you have an idea an idea of how you're going to do it?

If all binaries should move to /usr/bin, I count 354 (+12 testing) packages in the repos (without AUR) with files in /sbin, /bin and /usr/sbin which have to be rebuilt.

$ pacman -Sql | xargs -n1 pkgfile -l | grep "\s/s\?bin/\|/usr/sbin/" | cut -f1 | sort | uniq

Last edited by progandy (2013-04-01 18:56:12)

frony0 · 2013-04-01 20:21:03

progandy wrote:

Do you have an idea an idea of how you're going to do it?
If all binaries should move to /usr/bin, I count 354 (+12 testing) packages in the repos (without AUR) with files in /sbin, /bin and /usr/sbin which have to be rebuilt.
$ pacman -Sql | xargs -n1 pkgfile -l | grep "\s/s\?bin/\|/usr/sbin/" | cut -f1 | sort | uniq

Oh so it's just a case of moving the files in all the packages? Fair enough. I'd be happy to help, if you guys ever need!

Arch Linux

#1 2012-08-30 22:09:12

Merge /{s,}bin with /usr/{s,}bin

#2 2012-08-30 22:35:12

Re: Merge /{s,}bin with /usr/{s,}bin

#3 2012-08-30 22:36:19

Re: Merge /{s,}bin with /usr/{s,}bin

#4 2012-08-31 03:51:02

Re: Merge /{s,}bin with /usr/{s,}bin

#5 2012-08-31 08:09:24

Re: Merge /{s,}bin with /usr/{s,}bin

#6 2012-08-31 13:55:03

Re: Merge /{s,}bin with /usr/{s,}bin

#7 2012-08-31 16:07:37

Re: Merge /{s,}bin with /usr/{s,}bin

#8 2012-09-01 06:16:54

Re: Merge /{s,}bin with /usr/{s,}bin

#9 2012-09-01 18:06:51

Re: Merge /{s,}bin with /usr/{s,}bin

#10 2012-09-01 18:24:41

Re: Merge /{s,}bin with /usr/{s,}bin

#11 2012-09-01 18:49:10

Re: Merge /{s,}bin with /usr/{s,}bin

#12 2012-09-02 20:09:37

Re: Merge /{s,}bin with /usr/{s,}bin

#13 2012-09-02 22:27:35

Re: Merge /{s,}bin with /usr/{s,}bin

#14 2012-09-08 10:38:02

Re: Merge /{s,}bin with /usr/{s,}bin

#15 2012-09-15 04:36:26

Re: Merge /{s,}bin with /usr/{s,}bin

#16 2012-09-15 14:12:19

Re: Merge /{s,}bin with /usr/{s,}bin

#17 2013-04-01 10:42:54

Re: Merge /{s,}bin with /usr/{s,}bin

#18 2013-04-01 10:52:05

Re: Merge /{s,}bin with /usr/{s,}bin

#19 2013-04-01 10:55:01

Re: Merge /{s,}bin with /usr/{s,}bin

#20 2013-04-01 13:00:53

Re: Merge /{s,}bin with /usr/{s,}bin

#21 2013-04-01 13:09:22

Re: Merge /{s,}bin with /usr/{s,}bin

#22 2013-04-01 14:37:39

Re: Merge /{s,}bin with /usr/{s,}bin

#23 2013-04-01 18:53:53

Re: Merge /{s,}bin with /usr/{s,}bin

#24 2013-04-01 20:21:03

Re: Merge /{s,}bin with /usr/{s,}bin

Board footer