When building ImageMagick-6.2.5.4-4.2.1.fc5.3.i386 as it is and trying to 
install using latest RPM:

> libtool(/usr/lib/libMagick.la) is needed by ImageMagick-6.2.5.4-4.2.1.fc5.3.
i386

That's fine, because no %{_libdir}/*.la is shipped in Fedora Core. Adding all
*.la to ImageMagick-devel-6.2.5.4-4.2.1.fc5.3.i386 causes this at installing
(to be correct, I'm trying to install main package + -devel package):

> libtool(/usr/lib/libMagick.la) is needed by ImageMagick-6.2.5.4-4.2.1.fc5.3.
i386
> libtool(/usr/lib/libMagick.la) is needed by ImageMagick-devel-6.2.5.4-4.2.1.
fc5.3.i386
> libtool(/usr/lib/libWand.la) is needed by ImageMagick-devel-6.2.5.4-4.2.1.fc5.
3.i386

Aha? But:

# rpm -qpl ImageMagick-devel-6.2.5.4-4.2.1.fc5.3.i386.rpm | grep "\\.la"
/usr/lib/libMagick++.la
/usr/lib/libMagick.la
/usr/lib/libWand.la
#

Ta ta...why the hell is RPM nagging about a *provided* dependency? When all
*.la files are available, RPM shouldn't complain about them, shouldn't it?

The "contain"ed path /usr/lib/libMagick.la != the "provide"ed dependency libtool(/usr/lib/libMagick.la).

The two are different.

Sort out the problem by doing
    echo /usr/lib/libMagick.la | /usr/lib/rpm/libtooldeps.sh --provides /
and
    echo /usr/lib/libMagick.la | /usr/lib/rpm/libtooldeps.sh --requires /

Note the final "/" arg, the 2nd argument is normally %{buildroot}.

The libtool dependency in libMagick is actually necessary (as currently implemented, see #185237 
comment 2).

The general answer for libtool dependencies is unclear while FC is still involved in radically eliminating 
every instance of *.la files. Whatever solution "works" for FC is unlikely to be useful for other distros that 
are not eliminating *.la files.

Deferred until hell freezes ...

Jeff, I think you are confusing .la files for loadable modules/plugins and .la
files associated with shared libraries.  rpm should *only* be concerned with the
latter.  Now, I won't argue that it may be difficult to determine the difference
simply by looking at a .la file, but I don't think it would be unreasonable (as
a first pass) to limit rpm's automatic creation/extraction of libtool
dependancies to the pattern:
%{_libdir}/lib*.la

In ImageMagick's case, the dependancies are are *not* necessary, only that the
.la files be present.  (ImageMagick's packager omitted the plugin .la files).

If this isn't fixed, many packages, particularly kde ones, are going to end up
pulling in many, many bogus/extraneous dependancies on -devel pkgs (See related
kde bug #170602)

I am not confused, you are.

Have you tried rpm-4.4.7?

Have you looked at /usr/lib/rpm/libtooldeps.sh?

Have you thought about whether you want to turn the libtool dependencies on or off?

Or do you prefer to carp at me instead about how much will break if *.la dependencies are used ...

Patches cheerfully accepted from doeers, not talkers ...

No, I haven't looked at rpm-4.4.7.  Don't have any rawhide boxes (and as far as
I can tell, rawhide is still at rpm-4.4.2?)

I was simply refuting bits from your comment #3:

* "The libtool dependency in libMagick is actually necessary".  In this
(ImageMagick's) case, an rpm-generated libtool dependancy was *not* necessary.

* "The general answer for libtool dependencies is unclear".  To me, the general
answer *is* clear.  libtool dependancies for shared libs: good.  libtool
dependancies for everything else: bad.  For the former case of of shared libs,
the future need for rpm-generated libtool dependancies will (hopefully) be
minimized, since as you pointed out, FC is working to remove these
viral-infecting shared-lib type of .la files.

Now, I'm off to find rpm-4.4.7 to see exactly what libtooldeps.sh *does* and
*does not* do.

"actually necessary" -- if the loadable module mentioned in the *.la file is not actually present, then the 
load will fail. This can be tracked with a dependency, and that failure can be detected.

FWIW, rpm-4.4.7 can do the verification at install-time, not just at build time, if necessary.

"viral-infecting shared-lib" -- lose the attitude dude. *.la files (and libtool) implements functionality 
that pkgconfig doesn't even begin to implement.

E.g. rpm is built with certain libraries internal or external, and libtool makes that choice maintainable, 
otherwise a gory mass of Makefile rules would be needed to merge an internal (and uninstalled)  library.

Whether FC will succeed in killing off *.la files universally is still open to question. Good luck!

Ironically, *.la dependencies were a feature request from a FC developer, see #1559221.

Just took a look at libtooldeps.sh from rpm-4.4.7, and it is as a had only
previously assumed.  It creates Provides/Requires for all *.la files.  I would
argue (still) that it should limit itself to only /usr/lib/lib*.la files.  Patch
against rpm-4.4.7 forthcoming...

> "viral-infecting shared-lib" -- lose the attitude dude

Ha.  Good one, coming from you, that just made my day.  (: (no offense, you're
my hero).

Don't get me wrong, I'm not denigrading .la files in any way.  They're great and
have invaluable usefulness in building and maintaining software.  And, I hope,
that no-one is advocating the universal killing-off of .la files.  I'm only
speaking in the context of rpm packaging and including .la files assocated with
shared libraries.

> Ironically, *.la dependencies were a feature request from a FC developer
> see bug #159221 â RFE: track libtool .la dependencies

Yep, Nalin was talking about shared-lib .la files too (at least the examples he
gave did).

In the context of software *packaging*, shared-lib .la files, in general, just
plain suck.  When/if using systems with good shared libraries (and avoiding the
static lib/linking cases), .la files are generally unnessessary and lead to
needless dependancies (e.g, are virual):  

Here's a crazy-but-not-too-far-from-reality example:
Build shared-lib pkg 'b' which links against 'a'.  b's .la files now include
references to 'liba.la' (so now depends on it).  Build shared-lib pkg 'c' which
links against 'b', whose own libc.la file includes references(+dependancy) on
libb.la.  Rinse, lather, repeat.  You'll end up with a pkg z, and a libz.la,
which, when all is said and done, 
* will have a direct dependancy upon y's liby.la
* and because of liby.la file references/dependances, will have (indirect)
dependancies upon liba.la, libb.la, ..., libx.la
When, generally, *none* of these are really required nor desired.

The fix for this is easy too.  At each stage, simply omit %%_libdir/lib*.la from
packaging.  You end up with a nice, clean libz, which may or may not depend on
liby, and which almost certainly doesn't depend on liba, ..., libx.

This is, as I understand it, the basis for the campaign to remove shared-lib .la
files from Fedora Core.

Adding a case to limit extraction to /lib* and /usr/lib* is trivially achieved if/when anybody actually 
starts using or needing *.la dependencies. The adoption time for new functionality in rpm is now over 2 
years, so I vae at least another year to fix the libtool extraction.

Sure, in the linkage case libA -> libB -> libC there is the possibility of redundant dependencies.

Does -lB imply -lC implicitly or explicitly? The explicit (in my words) case is when libA is linked with "-
lB -lC", which can lead to a redundant dependency of A -> C.

That is true for any means of linking libraries, either ELF DT_NEEDED within shared libraries, or through 
*.la dependent library specs. The problem is general, not specific to libtool *.la.

However, for various hysterical reasons, the intent in RHL package way back when was to consciously 
and explictly link libA with "-lB -lC", the idea (iirc) being to localize dependency information and work 
around some arcane ELF bustage that has long since been repaired. Whether that was necessary or wise 
is a whole different question.

I'll have to check to see whether libtool permits dropping intervening libraries. One can certainly
used sed on libA.la to remove "... -lC" when building/packaging if necessary,.