Re: directory under /usr/bin -- Ok or not?
On Sun, 06 Nov 2011, Steve Langasek wrote:
> 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.
>
> What is the justification for making this a separate directory from
> /usr/lib (especially given that /usr/lib has now been part of Debian policy
AFAIK there is none [in Linux], but the fact that a very large number of
others do it anyway, and it is not exactly going to cause technical
problems to diverge less from upstream in this specific issue.
libexec really exists as something to offload stuff that would end up in
/usr/sbin and /sbin to. We've been using lib for that for a long time
without any issues, so we don't really *need* to do it.
> for a decade or so)? What is the transition plan for migrating from
> /usr/lib to /usr/libexec?
Do we even need one? If upstream places stuff in libexec and is not on
crack, you move that stuff back into libexec *if you want to, as the
maintainer of the package*. If you don't care for libexec, or if
upstream doesn't use libexec anyway, you keep using lib.
Not that I care either way, libexec really is fluff, but at least it is
harmless fluff that will cost us one inode in / and one inode in /usr so
if people want it, I certainly won't get in the way.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: