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 -- 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/20111107002637.ga7...@amos.fritz.box
