[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: directory under /usr/bin -- Ok or not?

On Wed, 02 Nov 2011, Roger Leigh wrote:
> > Altogether, according to FHS /usr/lib/PKG is actually not preferable
> > location for them since indeed it is for solely internal use (and it is
> > now used to keep shared libraries)
> This is just nitpicking over the precise wording used.  

really?  since when it is nitpicking to quote FHS verbatim? once again:

    "The following directories, or symbolic links to directories, must be in
    /usr/bin, if the corresponding subsystem is installed:

    Directory   Description
    mh  Commands for the MH mail handling system (optional)"


> In practice,
> this *is* where they belong, and it is what every other package does
> (for example, postgresql).  You can add that specific directory to
> your path, should you choose.

and I have been doing that for quite a few packages myself -- so I am
quite aware of this current "common practice".  And that is why I
actually decided to check among standards and ask here either it
is mandated, because I always felt that executing anything from /usr/lib
felt awkward.

You might consider me blind or naive -- but so far none of the arguments
for not having a subdirectory under /usr/bin had any strongly supported

> When considering the divide between "internal use" and "for users",
> consider that if it's for users to invoke then it should simply be
> in the default path.  It's not typical to need to add special
> directories to one's path, and it's certainly not encouraged or
> recommended.

Well -- that is all cool and in an ideal world  I am with you on this
one.  BUT it is often the case (e.g.  with scientific software) that
suite provide bulk of (>100) cmdline tools.  Some of those come without
unique names and are already widely used by people running Debian or
whatnot, so changing their habbits/scripts is not as easy as "lets just
renamed them".  Sure thing we recommend upstream either coming up with
custom prefixes/unique names or gateway wrappers to avoid conflicts
and/or reduce hit on the proliferation of namespace of cmdline tools...
But once again -- it ain't happening at once and for all, so let's
not discuss this aspect further here.

Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

Reply to: