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

[Ralf Corsepius]

On Wed, 2006-10-04 at 00:31 -0700, Toshio Kuratomi wrote:
> 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.
Where?

All Fedora has is libs somewhere on the file system, being searched for
at run-time by ld.so, and searched for by GCC/ld/etc. at link-time with
paths being composed by arbitrary "configure scripts".

There is no guarantee run-time deps are satisfied or complete, neither
at run-time nor at link-time, but rpm's deps.

=> Without *.la you can exchange (and brake) a libraries/applications
dependencies unnoticed.

> > * 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?
ATM, this case doesn't exist, but it would be easy to construct, e.g. by
introducing compat-*devel packages being designed to exist in parallel.

> > * 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.
In a nutshell, I mean "*.pc's are equally broken and not any better than
*.la's". 

They don't suffer from the same issues as *.la's but they also suffer
from defects, e.g.
* language specific compiler flags in *.pc
* compiler/compiler-version specific compiler flags in *.pc
* Incorrect hard-coded libs (-l<something>)
* Incorrect (Missing rsp. superfluous) deps (Requires: foo)
* pkgconfig not properly separating CPPFLAGS/CFLAGS/CXXFLAGS/FFLAGS
* being manually written.
* being static (They denote a situation having being valid at one point
in time - There is no guarantee it still is, nor that they match ld.so's
configuration.).
...

Ralf