[Fedora-packaging] Re: libtool(.la) archive policy proposal

[Toshio Kuratomi]

On Wed, 2006-10-04 at 07:54 +0200, Ralf Corsepius wrote:
> On Tue, 2006-10-03 at 22:16 -0700, Toshio Kuratomi wrote:
> > On Wed, 2006-10-04 at 06:25 +0200, Ralf Corsepius wrote:
> > > Also consider: Any package using libtool by default installs *.la's, any
> > > package's author (Note: author, not Fedora package maintainer) has the
> > > liberty of removing them upon installation as part of his package's
> > > "installation step", if he thinks they are harmful/not useful.
> > 
> > You're wrong.  *.la's provides benefit to upstream.  It does not always
> > provide benefits to downstream.  Therefore it is downstream which must
> > make the decision whether to remove the .la files.
> 
> > If you know of a feature that *.la's provide on Fedora that otherwise is
> > not present,
> 
> * library dependencies.
We have this already.

> * rpath (consider parallel installed package, e.g. openmotif in parallel to lesscrap)
We have this manually, *.la's add it automatically.  For the motif case,
it seems that lesstif installs to %{_libdir} and has no rpath set so it
doesn't need a *.la.  openmotif, as a non-Fedora package, is free to
install wherever it pleases with whatever rpath it likes and use *.la's
to implement its choice.  Can you point me to two Fedora packages that
need to parallel install libraries?

> * redundancy - Remember: Conflicts between *.la's, *.pc's, ld.so.conf
> and rpm deps not always are libtool's fault. Esp. *.pc's are MANUALLY
> written.
> * Inconsistent flags: Remember *.pc's are manually written. Some people
> tend to abuse CFlags in *.pcs.
> 
Unless I'm misunderstanding what you mean, these are bugs and should be
fixed, not ignored because we have *.la's.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20061004/4c4cffc0/attachment.sig>