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

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

Yaroslav Halchenko <debian@onerussian.com> writes:

> Thank you John for extending my argument with adequate references which
> I have swallowed while  composing my question email.
> And if we are after reading FHS /usr/lib section:
>     /usr/lib includes object files, libraries, and internal binaries that
>     are not intended to be executed directly by users or shell scripts.
> and in my case it becomes more interesting -- those tools *are intended*
> to be executed by (interested) users directly.  It is just due to proliferation
> in number of the tools and conflicts with other packages they cannot go under
> /usr/bin directly.

But if you have /usr/bin/foo/bar then how is the user supposed to
execute it? "foo/bar" won't work.

And if you have to type in the full path every time that would be pretty
anoying and no improvement over /usr/lib/foo/bar.

I would rather use /usr/bin/foo-bar in that case, e.g. git-import-dsc.

> That is why for this package (as for few others we maintain already) we
> are shipping also /etc/PKG/pkg.sh script so (interested) users could
> source to have their PATH adjusted to get preference to execute tools
> from the PKG instead of possibly available conflicting one under
> /usr/bin.   Wrapper script shipped directly under /usr/bin/ is only for
> possible future adoption  since at the moment all users (and their
> scripts) rely on direct names of the cmdline tools.

Adding /usr/lib/PKG to the PATH seems just a viable.

As for wrapper scripts. If you can put a wrapper script in /usr/bin then
you can just as easily just put the binary there in the first place.

> 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)

There you might have a point.


Reply to: