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

[Michael Schwendt]

On Mon, 02 Oct 2006 19:36:48 +0200, Ralf Corsepius wrote:

> Yes, because libtool aims at portability. What you call "indirect deps"
> is non-portable, therefore libtool keeps this info around.
> 
> > The BuildRequires pile up -- unless the packagers fix them bottom-up
> > because they examine the new .la file(s). If they don't, wrong BR move up
> > in the dep-chain. Guess what happens if libfoo is upgraded and now
> > build-requires libd.la.  This requires additional BR in "foo", although
> > "foo" doesn't depend on libd directly.
> > 
> > Worse, libtool inter-library dependencies often are hardcoded as
> > absolute paths, e.g. /usr/lib/liba.la.
>
> And what is the problem? Outside of the linux world, shared-libs are
> non-relocatible.

We're not "outside of the linux world". You make a big thing out of
"features", which we don't need, because they increase the trouble.  They
also add the possibility of "feature abuse". Source tarball vendors who
hack "stuff" into libtool files to make the end-product work even less
good.
 
> > Removal of any .la from the entire dep-chain bears a very big risk of
> > requiring a rebuild of the entire dep-chain bottom-up plus pruning the
> > spec BR/Reqs, also bottom-up.
>
> This is not a risk - this is a feature.

So what? It means: increased maintenance requirements that sucks.

> > > From a different view: *.la files aren't much different than *.pc
> > > files, in fact they contain a subset of their information. One
> > > wouldn't argue to remove all *.pc files because some may contain too
> > > many references to libs.
> > 
> > These are broken and partially have their origin in "extreme static
> > linking". (For static linking you need the full chain of -lfoo arguments,
> > as everything else would result in missing symbols).
>
> Wrong: They have their origin in portability. Only fully linking is
> portable. Packages aiming at portability can not and must not avoid
> these deps.

Insert comment from above here, too. It's fine from the perspective of the
vendor of the source tarball. I've made good use of libtool long ago.
Still the "feature bloat" is a hindrance at the RPM packaging level the
longer the inter-library dependency-chain becomes.