+1 (as change owner)

+1

Vigorous +1

+1

Appreciate the detailed proposal, too.

+1

0

I am indifferent to this change. This is more of a housekeeping thing which is fine, but our lives will still be filled with PATHs containing bin and sbin directories, for script portability. In the worse case, I see this leading to poorly written scripts that cannot run on older EL releases or other operating systems.

And the alarmist in me reminds me of an actual real problem we encountered over 15 years ago on Fedora installations on ext3 filesystems. inode limits. Also dentry limits. Given the ability to do wild things, users will eventually do them. In a hypothetical situation, a user may be experimenting on some unusual hardware and it needs a special kernel and for whatever reason has to use a filesystem other than something we typically use. If the user is trying to manually stand up Fedora in this environment, having a really large directory of files could present a problem for them. We could take the position of wanting Fedora to be accessible for experimentation like this or the position of not supported and leave it at that. This is a hypothetical example and I am basing it on caution I would take given my previous experience.

At any rate, I am not going to stand in the way of this change, just everyone remember to not assume your PATH anywhere. :)

+1

but our lives will still be filled with PATHs containing bin and sbin directories, for script portability

I'm not sure what exactly you mean, but with either interpretation, is seems to be a misunderstanding. If you mean that scripts will use explicit paths to binaries, then this change doesn't matter: any scripts which calls /usr/sbin/foo because there's some system with split-sbin can continue to do just that and nothing will change. If you mean that scripts set $PATH at their beginning to "work better" on systems where the variable is not set properly in the environment, they can continue to do so, and they will work as before. I think doing either of those things is of dubious value, but the proposed change doesn't cause problems in either scenario. OTOH, if you mean that the $PATH that we set will include both sets of directories, then this is not true, we will do the deduplication, similarly to how it has happened for /bin and /sbin.

inode limits. Also dentry limits.

Well, this change will lead to a reduction in use of both. But even if we consider the temporary state where we have some extra symlinks, we're talking about a few dozen files, so not really a problem even on the strangest filesystems.

but our lives will still be filled with PATHs containing bin and sbin directories, for script portability

I'm not sure what exactly you mean, but with either interpretation, is seems to be a misunderstanding. If you mean that scripts will use explicit paths to binaries, then this change doesn't matter: any scripts which calls /usr/sbin/foo because there's some system with split-sbin can continue to do just that and nothing will change. If you mean that scripts set $PATH at their beginning to "work better" on systems where the variable is not set properly in the environment, they can continue to do so, and they will work as before. I think doing either of those things is of dubious value, but the proposed change doesn't cause problems in either scenario. OTOH, if you mean that the $PATH that we set will include both sets of directories, then this is not true, we will do the deduplication, similarly to how it has happened for /bin and /sbin.

I just meant this is a system change that won't (or shouldn't) effect shell scripts that people write. So I view this is a no-op change that won't really lead to any meaningful change for users and therefore I question why we even care about doing this.

On the mailing list, Panu mentioned a different approach of pulling executables out of sbin that we explicitly do not want users to invoke. I think that is a better idea because I am not convinced everything in sbin is really something all users should have in their default path. The categories of executables these days go beyond the split of "thing a user can run" and "thing the admin can run". Nearly every system is using sudo or a similar approach to elevate a regular user to admin to perform certain tasks. But even that's gotten more complicated. sudo allows for further customization to restrict a user to only specific modes of invoking a program (e.g. specific options or subcommands or something like that). Then there are daemons that are invoked by the system manager and those have lived in sbin because historically they could be run directly by the admin but were often just run by an init script. Perhaps it's time to move those elsewhere, such as /usr/libexec. I think there are improvements we can make here but I would prefer to see more fundamental design changes than just merging two subdirectories of executables.

The above approach requires more work and thought. But by itself, this change as written is really just going to mean Fedora systems will have a shorter default PATH variable or no PATH variable. I don't view that as an important change.

There were other comments as well regarding man page sections, which also carries some validity.

After a week: APPROVED (+6, 1, 0)

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UBVG6IOTUHHY5SHXFHOISZNHK3QLXTMX/