Am Sun, 12 May 2013 02:56:50 -0300 schrieb Gerardo Exequiel Pozzi :

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 2013/5/12 Allan McRae wrote:

On 12/05/13 18:58, Andreas Radke wrote:

...

Am Sun, 12 May 2013 02:56:50 -0300 schrieb Gerardo Exequiel Pozzi :

...

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 7:56 AM, Gerardo Exequiel Pozzi 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

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 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 Sun, May 12, 2013 at 10: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)

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

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