[arch-dev-public] Merging the "bin" directories
Hi, Now the dust has settled on the /lib -> usr/lib move and pacman-4.1 is out (which has some fixes in this area), it is time to start looking at doing the rest of the usr merge. I have created a TODO list with all packages that have files in /bin, /sbin or /usr/sbin. As the list is fairly long, the first pass will be to adjust as many packages as possible to install their files in /usr/bin instead. Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks. Once we see how many packages are left, we can start planning to finally get rid of these directories. Allan
On 05/12/2013 02:22 AM, Allan McRae wrote:
Hi,
Now the dust has settled on the /lib -> usr/lib move and pacman-4.1 is out (which has some fixes in this area), it is time to start looking at doing the rest of the usr merge.
I have created a TODO list with all packages that have files in /bin, /sbin or /usr/sbin. As the list is fairly long, the first pass will be to adjust as many packages as possible to install their files in /usr/bin instead. Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks.
Once we see how many packages are left, we can start planning to finally get rid of these directories.
Allan
Looks like we are going "one step" more compared to Fedora right? /bin /sbin /usr/sbin -> /usr/bin (Arch Linux) /bin -> /usr/bin AND /sbin -> /usr/sbin (Fedora) This looks nice :) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am Sun, 12 May 2013 02:56:50 -0300 schrieb Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
Looks like we are going "one step" more compared to Fedora right?
/bin /sbin /usr/sbin -> /usr/bin (Arch Linux) /bin -> /usr/bin AND /sbin -> /usr/sbin (Fedora)
This looks nice :)
Is it safe to move a daemon to /usr/bin where any user can access its binary (e.g. my cups pkg)? -Andy
On 12/05/13 18:58, Andreas Radke wrote:
Am Sun, 12 May 2013 02:56:50 -0300 schrieb Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
Looks like we are going "one step" more compared to Fedora right?
/bin /sbin /usr/sbin -> /usr/bin (Arch Linux) /bin -> /usr/bin AND /sbin -> /usr/sbin (Fedora)
This looks nice :)
Is it safe to move a daemon to /usr/bin where any user can access its binary (e.g. my cups pkg)?
Sure... They were not magically hidden when in /usr/sbin.
On 2013/5/12 Allan McRae <allan@archlinux.org> wrote:
On 12/05/13 18:58, Andreas Radke wrote:
Am Sun, 12 May 2013 02:56:50 -0300 schrieb Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
Looks like we are going "one step" more compared to Fedora right?
/bin /sbin /usr/sbin -> /usr/bin (Arch Linux) /bin -> /usr/bin AND /sbin -> /usr/sbin (Fedora)
This looks nice :)
Is it safe to move a daemon to /usr/bin where any user can access its binary (e.g. my cups pkg)?
Sure... They were not magically hidden when in /usr/sbin.
It is even a pain that very useful binaries like ip, ifconfig, lsof are in /sbin or /usr/sbin which is often not in user's PATH. Rémy.
On Sun, May 12, 2013 at 11:58 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
Is it safe to move a daemon to /usr/bin where any user can access its binary (e.g. my cups pkg)?
Sure... They were not magically hidden when in /usr/sbin.
It is even a pain that very useful binaries like ip, ifconfig, lsof are in /sbin or /usr/sbin which is often not in user's PATH.
Yeah, split sbin was always a pain. Which (if I remember correctly) is why we have been putting it in the user's PATH for some time (in effect making the split meaningless). -t
On Sun, May 12, 2013 at 7:56 AM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Looks like we are going "one step" more compared to Fedora right?
/bin /sbin /usr/sbin -> /usr/bin (Arch Linux) /bin -> /usr/bin AND /sbin -> /usr/sbin (Fedora)
Correct. For what it's worth, I asked the Fedora guys if there was a good reason they didn't go all the way, and there wasn't (they plan to do it in the future). Cheers, Tom
Am 12.05.2013 07:22, schrieb Allan McRae:
I have created a TODO list with all packages that have files in /bin, /sbin or /usr/sbin. As the list is fairly long, the first pass will be to adjust as many packages as possible to install their files in /usr/bin instead. Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks.
List of showstoppers: - Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin) - Binaries that are used in services outside their package (obviously, we then need to fix those services) - Binaries that are hardcoded in scripts with their paths (fix those scripts, actually)
On 12.05.2013 10:44, Thomas Bächler wrote:
List of showstoppers:
- Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin) - Binaries that are used in services outside their package (obviously, we then need to fix those services) - Binaries that are hardcoded in scripts with their paths (fix those scripts, actually)
- Binaries that are hardcoded in config files. rsnapshot hardcodes the path to du, cp, mv, rm and friends. Perl's cpan (or maybe cpanplus) hardcodes some paths too. I'm pretty sure there are more... Do we care? Given we care about shells, we probably do.
On 12/05/13 19:27, Florian Pritz wrote:
On 12.05.2013 10:44, Thomas Bächler wrote:
List of showstoppers:
- Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin) - Binaries that are used in services outside their package (obviously, we then need to fix those services) - Binaries that are hardcoded in scripts with their paths (fix those scripts, actually)
- Binaries that are hardcoded in config files.
rsnapshot hardcodes the path to du, cp, mv, rm and friends.
All those are not being moved until the final stage.
On 05/12/2013 05:44 AM, Thomas Bächler wrote:
Am 12.05.2013 07:22, schrieb Allan McRae:
I have created a TODO list with all packages that have files in /bin, /sbin or /usr/sbin. As the list is fairly long, the first pass will be to adjust as many packages as possible to install their files in /usr/bin instead. Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks.
List of showstoppers:
- Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin) - Binaries that are used in services outside their package (obviously, we then need to fix those services) - Binaries that are hardcoded in scripts with their paths (fix those scripts, actually)
Another possible: - same filename between two package in "bin" vs "sbin". Example: $ pacman -Qo /usr/sbin/nfsiostat /usr/sbin/nfsiostat is owned by nfs-utils 1.2.7-1 $ pacman -Qo /usr/bin/nfsiostat /usr/bin/nfsiostat is owned by sysstat 10.1.5-1 -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Sunday 12 May 2013 07:46:37 Gerardo Exequiel Pozzi wrote:
$ pacman -Qo /usr/sbin/nfsiostat /usr/sbin/nfsiostat is owned by nfs-utils 1.2.7-1 $ pacman -Qo /usr/bin/nfsiostat /usr/bin/nfsiostat is owned by sysstat 10.1.5-1
Just a note here: upstream already knows about this[1] since a month, but didn't reply to the OpenSuSE maintainer. [1] http://article.gmane.org/gmane.linux.nfs/55922 -- Andrea Arch Linux Developer
On Sun, May 12, 2013 at 10:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 12.05.2013 07:22, schrieb Allan McRae:
I have created a TODO list with all packages that have files in /bin, /sbin or /usr/sbin. As the list is fairly long, the first pass will be to adjust as many packages as possible to install their files in /usr/bin instead. Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks.
List of showstoppers:
- Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin)
All mount and fsck helpers should be ok to move to /usr/bin. At least from mount and fsck's point of view, did you have something else in mind?. -t
Am 12.05.2013 13:13, schrieb Tom Gundersen:
List of showstoppers:
- Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin)
All mount and fsck helpers should be ok to move to /usr/bin. At least from mount and fsck's point of view, did you have something else in mind?.
They used to be hardcoded to /sbin/mount.$FOO and /sbin/fsck.$FOO, has that changed?
On Sun, May 12, 2013 at 01:54:34PM +0200, Thomas Bächler wrote:
Am 12.05.2013 13:13, schrieb Tom Gundersen:
List of showstoppers:
- Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin)
All mount and fsck helpers should be ok to move to /usr/bin. At least from mount and fsck's point of view, did you have something else in mind?.
They used to be hardcoded to /sbin/mount.$FOO and /sbin/fsck.$FOO, has that changed?
It's okay to move helpers like fsck.ext4 -- fsck itself has a lookup path which we can set to whatever we want. We currently append /usr/bin:/usr/sbin to the default of /sbin:/sbin/fs.d:/sbin/fs. It's not okay to move /sbin/fsck itself. $ strings /usr/lib/systemd/systemd-fsck | grep -F /sbin/fsck /sbin/fsck
On Sun, May 12, 2013 at 1:54 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 12.05.2013 13:13, schrieb Tom Gundersen:
List of showstoppers:
- Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin)
All mount and fsck helpers should be ok to move to /usr/bin. At least from mount and fsck's point of view, did you have something else in mind?.
They used to be hardcoded to /sbin/mount.$FOO and /sbin/fsck.$FOO, has that changed? About mount (in front of libmount) it's implemented since[1] in mnt_context_prepare_helper.
We already have mount.cifs in /usr/bin and I tried successfully with mount.vboxsf. [1] https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=a29e2... -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On Sun, May 12, 2013 at 7:22 AM, Allan McRae <allan@archlinux.org> wrote:
Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks.
Once we see how many packages are left, we can start planning to finally get rid of these directories.
Can we think about doing this soon? There is 234 packages left and 453 have been fixed. I've lost network on 3 hosts by updating them and have systemd services which use /usr/sbin/{ethtool,sysctl}. There is also breakage to fcron users who doesn't take care immediately of .pacnew files. Instead of starting looking at which package can cause breakage or not, launching the final rebuild now will save admin time. Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On 24/05/13 11:17, Sébastien Luttringer wrote:
On Sun, May 12, 2013 at 7:22 AM, Allan McRae <allan@archlinux.org> wrote:
Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks.
Once we see how many packages are left, we can start planning to finally get rid of these directories.
Can we think about doing this soon? There is 234 packages left and 453 have been fixed.
I've lost network on 3 hosts by updating them and have systemd services which use /usr/sbin/{ethtool,sysctl}. There is also breakage to fcron users who doesn't take care immediately of .pacnew files. Instead of starting looking at which package can cause breakage or not, launching the final rebuild now will save admin time.
The final transition will be much, much easier if there is fewer packages to deal with. Looking at the remaining rebuilds, a large portion can still be moved without issues. As I said in the rebuild description, mark as complete any packages that need to wait. Allan
participants (10)
-
Allan McRae
-
Andrea Scarpino
-
Andreas Radke
-
Dave Reisner
-
Florian Pritz
-
Gerardo Exequiel Pozzi
-
Rémy Oudompheng
-
Sébastien Luttringer
-
Thomas Bächler
-
Tom Gundersen