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

Re: possible mass-filing of bugs: many shared library packages contain binaries in usr/bin

Wichert Akkerman <wichert@wiggy.net> writes:

> Previously Jeroen Dekkers wrote:
> > If you can't see the difference between a binary and a library it's
> > probably unuseful.
> The difference is technically really minimal. Look at glibc for
> example, which you can run as a normal binary as well.

That's true.  However, making libraries into executables is not
trivial, and is extremely limited--I have tried and failed to make it
work with ld's --entry.  You can only use syscalls, and no libc, which
is not all that fun.  Certainly not usable for anything serious (at
least without more knowledge of running without libc initialised,
otherwise all you get is segfaults in my experience).

> > I think it's better to not have binaries in /usr/lib.
> Why? Do you want to move scripts into /etcexec as well?

You asked for what the real purpose of libexec was, and in another
thread it was suggested that search times would be reduced, which is
not the point, IMHO.

On a system, we have (very generally):

bin and sbin for programs invokable by users, which are in and out of
             the standard PATH respectively.

lib for libraries.  I'll include binaries which may be either linked
             in at run-time or dlopened here, as well as libraries
             used by languages other than C, e.g. perl, python.

libexec fills a gap in the system.  If a package has a set of
             programs which should not be in the standard binary
             directories (they are too specialised, not for common
             use) and are not libraries, they are currently dumped in
             /usr/lib/<package>[/bin], which is not very neat.  They
             are not suitable to go in lib /or/ share, since it may
             include a mixture of scripts and binaries.

libexec, IMHO, serves to tidy up the filesystem by only using lib for
libraries, and putting extra binaries into libexec/<package>.  It
cleans up lib, which is (again IMHO) needed.  Having a place to put
the scripts will also be an incentive to move the remaining shareable
data under share.

An example of this is inn2, which has tens of small programs which are
used to do various jobs either invoked by the daemon, cron jobs or the
news user.  They are not in any way libraries, or library-related, but
exist in /usr/lib/news/bin.  They are ideal candidates for putting
into libexec.

The GNU Coding Standards define libexec as:
| `libexecdir'
|      The directory for installing executable programs to be run by other
|      programs rather than by users.  This directory should normally be
|      `/usr/local/libexec', but write it as `$(exec_prefix)/libexec'.

In short, I agree that libexec is `not essential', like you said
previously, but then again separating bin and sbin is not essential
either.  It does clean up the cruft that is dumped in /usr/lib
though, and I would like to see it used for just this reason.


Roger Leigh
                ** Registration Number: 151826, http://counter.li.org **
                Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: