Re: RES: /usr/lib vs /usr/libexec
On Tue, May 17, 2005 at 11:00:09AM -0700, Thomas Bushnell BSG wrote:
> Russ Allbery <rra@stanford.edu> writes:
>
> > I don't personally care on /usr/lib vs. /usr/libexec, except that the idea
> > of going through and changing all the packages in Debian really doesn't
> > appeal to me (and however easily spread that cost, it's a lot of work --
> > it's more work than the /usr/doc migration, and that was a PITA). I do
> > care a *lot* about consistency. Having a mix of /usr/lib and /usr/libexec
> > is, in my opinion, significantly worse than either one or the other.
>
> Most packages had files in /usr/doc. Most packages do not have files
> in /usr/lib at all, and most of those that do, wouldn't need to be
> changed.
I'm not quite understanding the benefit: some theoretical speed benefit
from reduced library searching (that would go away with the much more
general fix of making sure Debian configures filesystems with better-
than-O(n) searching by default; that is, making sure we're not in the
stone age), in exchange for cluttering /usr with another second-level
directory.
(I'd expect the dynamic linker to mostly deal with the soname symlinks,
anyway; moving them somewhere else, to get the searches away from the
shared and static libraries themselves, would probably would probably be
more effective. It even seems, intuitively, like the Right Thing, though
probably not worth the bother.)
Most applications I've seen that use libexec make it entirely trivial
to move it to /usr/lib: "./configure --libexecdir=/usr/lib". (I don't
think apps that don't do this, or something like it, should be a major
consideration here--take apps out of the stone age, don't clutter my
/usr ...)
I'm just not seeing any benefits that are worth bloating /usr.
--
Glenn Maynard
Reply to: