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.
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.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
