Locations of POSIX.2c binaries?

[Cy Schubert - ITSD Open Systems Group]

In message <Pine.NEB.3.96L.1010321104849.93779E-100000 at fledge.watson.org
>, Robe
rt Watson writes:
> 
> We recently committed our getfacl and setfacl tools to the base FreeBSD
> 5.0-CURRENT branch, and received a comment about the location of the
> files.  We placed them in /bin, in the style of our chmod, but comments
> indicated that many users expected them to be in /usr/bin, as that is what
> is used on Solaris.  Given that scripts tend to hard-code the location of
> important binaries, it would be nice to be consistent here.  As such, I am
> looking for some general views on how different implementors placed these
> (and other POSIX.2c) binaries in the file system.  We're perfectly happy
> to move to /usr/bin if that is more consistent, and it may well be. 

That depends on whether we expect to use them in single user state 
without /usr mounted.  I can't see using these commands without /usr 
mounted.  Chown(8) is in /usr/sbin because it isn't required for single 
user mode.  Chmod(1) is in /bin because there may be a situation where 
a binary necessary to put the system into multi-user state needs to 
have its execute bit turned on to repair the situation.

Getfacl(1) and setfacl(1) don't absolutely need to be in the root 
filesystem, as enough repairs can be done to get the system into 
multi-user state to repair the situation once the system is completely 
up.

On the other hand, if we wish to repair any situation immediately in 
single user state without /usr mounted, which is also a valid argument, 
they need to be in /usr/bin.

If they're in /bin they should also be statically linked.  If they're 
in /usr/bin they can be dynamically linked.

There are some binaries, e.g. su(1), that live in /bin on Solaris and 
/usr/bin in FreeBSD.  The proper place for them is in /usr/bin, however 
Solaris uses /bin/su to prompt the user for a password just before 
starting an interactive shell in single user state.  Hence their su(1) 
needs to be in /bin while ours doesn't.  I've made my FreeBSD systems 
compatible to Solaris in regard to su(1) by symlinking /bin/su to point 
to /usr/bin/su.  If getfacl(1) and setfacl(1) need to live in /bin, for 
the reasons I've discussed above, just create symlinks during 
installworld in /usr/bin for script compatibility.

I don't think where a binary lives is a big issue, though putting too 
much in the root filesystem could cause some grief for some, especially 
those who are upgrading and find that they have to repartition their 
disks to upgrade successfully.  (I personally make the root filesystem 
4 times larger than recommended to prepare for future growth deferring 
this problem as long as possible, but that's another issue entirely.)


Regards,                         Phone:  (250)387-8437
Cy Schubert                        Fax:  (250)387-5766
Team Leader, Sun/Alpha Team   Internet:  Cy.Schubert at osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message