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

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

Anyway, just throwing that out there.

Andreas Bombe

Reply to: