Keeping stuff in /bin, /lib, /sbin
 

This will be fun....


What is our ongoing policy on putting things in /bin, /lib and /sbin?

Here are things as I see them:

1) We already have a bunch of things in /bin and /sbin that depend on
libraries in /usr/lib rather than /lib.

2) Booting without /usr mounted is not supported

3) One day we might want to do the much talked about /bin -> /usr/bin
merge. _ONE DAY_... _MIGHT_...


So, do we continue putting thinks in /bin and /sbin? At this time I am
not talking about things that everybody expects to find in /{s,}bin
(e.g. what is supposed to be there according to the FHS), but things we
put there because we thought we should back when booting without /usr
mounted was possible (e.g. sleep, bzip2, cut, du, ...)

Moving these out of /{s,}bin would make it a lot easier if _ONE DAY_ we
do decide to merge /bin to /usr/bin. And I mean _A LOT_ easier...
Making changes like that is a real annoyance in a rolling release distro.

Allan

Keeping stuff in /bin, /lib, /sbin
 

Hi Allan,

Thanks for bringing this up.

On Mon, Jan 30, 2012 at 5:49 AM, Allan McRae <allan@archlinux.org> wrote:
> Moving these out of /{s,}bin would make it a lot easier if _ONE DAY_ we
> do decide to merge /bin to /usr/bin. *And I mean _A LOT_ easier...
> Making changes like that is a real annoyance in a rolling release distro.

Regardless of an eventual /bin -> /usr/bin symlink, I would be in
favor of the following (purely in the interest of KISS):

All new binaries/libraries go to /usr/{bin,lib} no matter what. That
is no /lib, /bin, /sbin or /usr/sbin.

All current libraries should be moved from /lib to /usr/lib (but not
in a hurry, just when the relevant maintainers find the time).

All binaries should be moved to /usr/bin unless that would cause
inconveniences/problems (but not in a hurry, just when the relevant
maintainers find the time).

I guess that's the same as you had in mind?

Examples of things that would not be affected (at least until an
eventual /bin -> /usr/bin move):

* The dynamic linker

* /lib/{firmware,udev,systemd,modprobe.d,modules,depmod.d } (anything non-.so)

* /bin/{bash,sh,agetty...} (and other things that will cause horrible breakage)


Just my two cents,

Tom

Keeping stuff in /bin, /lib, /sbin
 

On 2012/1/30 Tom Gundersen <teg@jklm.no> wrote:
> Hi Allan,
>
> Thanks for bringing this up.
>
> On Mon, Jan 30, 2012 at 5:49 AM, Allan McRae <allan@archlinux.org> wrote:
>> Moving these out of /{s,}bin would make it a lot easier if _ONE DAY_ we
>> do decide to merge /bin to /usr/bin. *And I mean _A LOT_ easier...
>> Making changes like that is a real annoyance in a rolling release distro.
>
> Regardless of an eventual /bin -> /usr/bin symlink, I would be in
> favor of the following (purely in the interest of KISS):
>
> All new binaries/libraries go to /usr/{bin,lib} no matter what. That
> is no /lib, /bin, /sbin or /usr/sbin.
>
> All current libraries should be moved from /lib to /usr/lib (but not
> in a hurry, just when the relevant maintainers find the time).
>
> All binaries should be moved to /usr/bin unless that would cause
> inconveniences/problems (but not in a hurry, just when the relevant
> maintainers find the time).

I'd say it should be doable to do the move for non-core packages.
There are not so many of them and things like zsh have really no
reason to be in /bin, it depends on so many things in /usr/*

Rémy.

Keeping stuff in /bin, /lib, /sbin
 

On Mon, Jan 30, 2012 at 1:31 PM, Rémy Oudompheng
<remyoudompheng@gmail.com> wrote:
> On 2012/1/30 Tom Gundersen <teg@jklm.no> wrote:
>> Hi Allan,
>>
>> Thanks for bringing this up.
>>
>> On Mon, Jan 30, 2012 at 5:49 AM, Allan McRae <allan@archlinux.org> wrote:
>>> Moving these out of /{s,}bin would make it a lot easier if _ONE DAY_ we
>>> do decide to merge /bin to /usr/bin. *And I mean _A LOT_ easier...
>>> Making changes like that is a real annoyance in a rolling release distro.
>>
>> Regardless of an eventual /bin -> /usr/bin symlink, I would be in
>> favor of the following (purely in the interest of KISS):
>>
>> All new binaries/libraries go to /usr/{bin,lib} no matter what. That
>> is no /lib, /bin, /sbin or /usr/sbin.
>>
>> All current libraries should be moved from /lib to /usr/lib (but not
>> in a hurry, just when the relevant maintainers find the time).
>>
>> All binaries should be moved to /usr/bin unless that would cause
>> inconveniences/problems (but not in a hurry, just when the relevant
>> maintainers find the time).
>
> I'd say it should be doable to do the move for non-core packages.
> There are not so many of them and things like zsh have really no
> reason to be in /bin, it depends on so many things in /usr/*

zsh is a really bad example; you'll break every script that starts
with #!/bin/zsh. Shells excluded, I do agree that not much in [extra]
probably needs to be in the root binary directories.

Keeping stuff in /bin, /lib, /sbin
 

On Mon, Jan 30, 2012 at 12:53 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Mon, Jan 30, 2012 at 5:49 AM, Allan McRae <allan@archlinux.org> wrote:
>> Moving these out of /{s,}bin would make it a lot easier if _ONE DAY_ we
>> do decide to merge /bin to /usr/bin. *And I mean _A LOT_ easier...
>> Making changes like that is a real annoyance in a rolling release distro.
>
> Regardless of an eventual /bin -> /usr/bin symlink, I would be in
> favor of the following (purely in the interest of KISS):
>
> All new binaries/libraries go to /usr/{bin,lib} no matter what. That
> is no /lib, /bin, /sbin or /usr/sbin.
>
> All current libraries should be moved from /lib to /usr/lib (but not
> in a hurry, just when the relevant maintainers find the time).
>
> All binaries should be moved to /usr/bin unless that would cause
> inconveniences/problems (but not in a hurry, just when the relevant
> maintainers find the time).

I'll implement this in the packages I maintain (util-linux and udev)
at their next release, unless there are any objections.

All libraries will move to /usr/lib. For the binaries I'll have a
closer look at what makes sense and post details when moving to
[testing] so people will get a chance to raise any concerns.

Cheers,

Tom