Yaroslav Halchenko <deb...@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.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obwdqmdh.fsf@frosties.localnet
