usage of /usr/bin

Polytropon freebsd at edvax.de
Wed Apr 7 10:39:44 UTC 2010


On Wed, 07 Apr 2010 17:13:13 +0800, Fbsd1 <fbsd1 at a1poweruser.com> wrote:
> But that is not true.

It is, and the example you're giving is one of the
exceptions that secures the truth of the statement
given in "man hier". :-)



> The postfix port populates /usr/bin. And I am sure 
> postfix is not the only port to do this also. 

Basically, there are ports that can be installed
outside /usr/local, or are especially intended to
be. For example postfix, a MTA that can replace
the system one's (sendmail), so it takes its
position. Other ports also allow the setting of
a certain PREFIX variable that will override /usr/local,
which is the default setting. Note that it isn't
very often done, and if it is, it is intended
(as the postfix example you've given, or the
sometimes requested statically linked bash
within the base system).



> This intermingling of 
> RELEASE binaries and port binaries in /usr/bin is a really big problem 
> when trying to build jails.

Yes, understandable.



> Any past ports which have been included into 
> the base release should not be in /usr period.

It has been the system administrator who decides to
install them there. If he insists on replacing some
part of the base system with a port, or to add a
port outside of /usr/local, it's his decision to
do so. Of course, this can lead into problems.



> Saying system user utilizes are in /user/bin then why is fdisk or 
> sysinstall not there also.

Because the creators of FreeBSD have decided that
those programs to belong to different "classes" of
programs, and according to "man hier":

/usr/sbin/sysinstall
     /usr/      contains the majority of user utilities and applications
                sbin/     system daemons & system utilities (executed by
                          users)

/sbin/fdisk
     /sbin/     system programs and administration utilities fundamental to
                both single-user and multi-user environments

There are often decisions that aren't obvious (or even
don't make sense) at first sight.



> That don't make sense.

There are some historical reasons for that. Would you
believe me if I told you that the mount binary historically
was /etc/mount? Or /etc/fsck? Or how about /bin/adm?

Other kinds of UNIX have different hierarchy concepts
and naming conventions. And Linux has many more.



> It time to modernize 
> the directory layout keeping all RELEASE binaries out of /usr.

Hmmm... modernize... I know of some Linux that maps all
the "historical" locations into Programs/ or Config/
subtrees... I'm not sure if I would be happy with FreeBSd
going the same way, or even further, because I usually
find things when I need to search from them, and I can
mostly do it by brain - rather than /usr/bin/find. :-)



> I would think moving the /usr RELEASE binaries by the RELEASE 
> development team is a far smaller task then reviewing all 21,500 ports 
> for the bad ones that don't target /usr/local/bin and then correcting 
> their make files.

If should be relatively easy to spot them by variations
of Makefile, especially the mentioned PREFIX setting
which needs to be overridden in order to leave /usr/local.
If I have that in mond correctly, LOCALBASE is the name
of the variable that controls where things are put; there
was another one called X11BASE, which is deprecated because
/usr/X11R6 is now "inside" /usr/local.



> Before jails this problem was not a problem, But with 
> the growing usage of jails this is becoming a major incentive to not use 
> jails at all.

On the other hand, if you encounter such a problem by the
presence of a nonstandard - meaning "not being part of
the base system" - mail transfer agent, then maybe its
documentation should mention to pay attention when using
it instead of what the system brings, so further problems
with jails can be avoided, or at least cured (by a correct
procedure given in the documentation).




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...


More information about the freebsd-questions mailing list