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

Re: PROPOSAL: libtool archive (`*.la) files in `-dev' packages



Hi Ben,

On  4 May, Ben Collins wrote:
 > On Tue, May 04, 1999 at 12:56:06PM -0500, Ossama Othman wrote:
 > > Opinions?  Would this be something we could add to our packing
 > > policies?
 > 
 > Just a simple question, how many packages (percentage guess) does this
 > stand to _help_? Even if most libraries are compiled with libtool, most
 > programs which link with it are not. I'm just a little concerned that
 > we will polute the /lib and /usr/lib directories for little advantage.

Hmm.  Ben, I really couldn't make an educated guess about how many
packages my proposal could stand to help.  However, I do think that
this number will grow as more and more applications rely on libtool to
generate shared libraries.  Usage of libtool certainly appears to be on
the rise.  I'm sure usage will grow even faster once libtool's
multilanguage support stabilizes.

I do agree with you regarding pollution of the library directories.  It
is something to be concerned about.  On my system, there are 94 entries
in /lib and 503 in /usr/lib.  Adding the `.la' files to the directories
could certainly have some sort of impact.

Bear with me here:  what if we "interpreted" the `.la' files as some
sort of configuration file?  Could we then put them in some other
"control" directory, like we do with package scripts?  Libtool would
have to be hacked in order for this to work, I think.  Perhaps a new
debhelper module could handle installation of `.la' files in the
"appropriate" place.  I realize that I'm not being too clear here.  I'm
just running through some alternatives, albeit not very good ones.  I'm
not even sure the libtool folks or anyone else would go for such an
idea.  Opinions?

In the meantime, could it hurt to ask maintainers to install `.la'
files?  I guess it might be better to wait until we decide what to do
about this issue.

Thanks,
-Ossama
-- 
Ossama Othman <othman@cs.wustl.edu>
Center for Distributed Object Computing, Washington University, St. Louis
58 60 1A E8 7A 66 F4 44  74 9F 3C D4 EF BF 35 88  1024/8A04D15D 1998/08/26


Reply to: