Control: severity -1 wishlist > This is a historical convention, going back decades, that only the > system administrators needs to run the programs in /sbin and > /usr/sbin. So to avoid users getting confused when they might run > those programs and get "permission denied", historically normal users > won't have /sbin and /usr/sbin in their path. However many system > administrators will have their own custom dot files which do include > those directories in their paths. > > That assumption is perhaps less likely to be true for servers running > in cloud VM', but making things be different for cloud VM's as > compared to standard Debian configurations also has downsides in terms > of causing greater confusion. So my suggestion would be for you to > simply have your own custom dotfiles which can set a PATH different > from the default. At this point, I think it'd be worth revisiting, at the project level, the historical tradition of leaving the sbin directories out of non-root paths. Setting aside all the single user desktop and laptop systems, there are enough alternative ways to grant restricted root (file ACLs, etc), and to run in alternate filesystem namespaces (e.g. containers), that the functional distinctions that lead to the original directory split are probably applicable in a minority of situations these days. This isn't something that I feel strongly about, though. Anybody who does should retitle this bug appropriately and reassign it to the 'general' pseudopackage, whereupon it can be discussed on debian-devel. Otherwise it should get tagged wontfix, unless someone thinks this is an appropriate change to introduce at the cloud image level (I would not agree with this). noah
Attachment:
signature.asc
Description: PGP signature