On 29 October 2015 at 16:13, Bruce Dubbs <[email protected]> wrote: > Pierre Labastie wrote: >> >> Hi, >> >> While running OpenJDK tests, I realized that one test was failing because >> it >> expected to find "uptime" in /usr/bin, but we install it in /bin, as we do >> for >> all procps executables (One could complain that tests shouldn't hard code >> paths, but it is not my point). This raises the question of what files >> should >> go into /bin (and /sbin). >> >> I cannot see how "uptime" could be needed early in the boot process, or in >> case /usr is not mountable. Same for "free", "w", more arguably for >> "watch", >> "top" and so on. >> >> OTOH, the FHS is clear: >> ------ >> /bin contains commands that may be used by both the system administrator >> and >> by users, but which are required when no other filesystems are mounted >> (e.g. >> in single user mode). It may also contain commands which are used >> indirectly >> by scripts. >> ------ >> >> My question is therefore: should we try to move some of the executables in >> /bin to /usr/bin? If yes, then the second question is "which executables". >> I >> can propose a list (only tomorrow actually; I'll have other things to do >> this >> afternoon and tonight) > > > We have the same problem with eudev where one of the regression tests hard > codes /usr/bin/test and we have it in /bin (where it needs to be). > > It's not unreasonable for uptime to be in /usr/bin, but as it is I only see > 107 executables in /bin and 11 of those are symbolic links. > > I don't think it's necessary to move files just because some upstream dev > hard coded a path into a test. Just use a sed to fix it.
It's not a random act by an "upstream dev"; as far as I can see all the above exist in /usr/bin in most, if not all, the mainstream distros. > > I think /bin/free should be in bin. I haven't used watch, but from the man > page, it might be useful in /bin. /bin/w and /bin/who are pretty > equivalent and may not be strictly needed in /bin, but it's not like we > overload /bin. Richard -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
