Re: directory under /usr/bin -- Ok or not?
On Sun, Nov 06, 2011 at 11:36:05PM +0000, Clint Adams wrote:
> On Sun, Nov 06, 2011 at 04:25:32PM +0100, Josselin Mouette wrote:
> > What is the use case?
>
> The use case is to have a place for executables that are treated
> similarly to libraries by other executables.
>
> For example, tcpd gets run by inetd but not by humans, so it
> would be silly to have it on root's PATH, so you put it in
> libexec.
>
> sftp-server gets run by sshd but is not a library, so it would
> be silly to have it in /usr/lib, so you put it in libexec.
I for one could see the tcpd case make sense… It does not belong on
root's $PATH, but since it needs to be available to other packages (such
as inetd) it can't be put in /usr/lib/$PACKAGE because then calling it
would depend on knowing the package providing that binary, an
implementation detail that might change.
The sftp-server on the other hand is provided by the package that also
contains its only caller AFAICS. That should be in /usr/lib/$PACKAGE
together with other package specific binary stuff — it doesn't make a
difference whether it's linked, dlopen()ed or exec()ed.
One could say public non-$PATH binaries should just go in /usr/lib
instead of a subdir then. However there's the problem with name
collisions with package subdirs. Libraries don't have that problem what
with them all being named *.a or *.so*.
I see sftp-server is in /usr/lib as a link to openssh-server and that
happens to work. tcpd wouldn't, for example. /usr/libexec would provide
a convenient separate namespace. As would /usr/lib/bin, but let's not go
there.
Anyway, just throwing that out there.
--
Andreas Bombe
Reply to: