On Tue, 2006-10-03 at 01:56 +0200, Michael Schwendt wrote:
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",
> > "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
We're not "outside of the linux world".
Yes, I sense certain circles
around here are striving for "living on the
island of RH/Fedora" ;)
You make a big thing out of
"features", which we don't need,
That's the point we both
repeatedly have clashed:
You are ignoring the API aspect of *.la's - *.la's are meant to be a
(semi-standardized) portability layer on top of library implementation
details, such as library names, versions, rpath etc.
> > 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.
I beg to differ.
Install libs outside of /usr/lib and in parallel to
those in /usr/lib and you'll probably pretty soon notice, why
RH/Fedora's habits/conventions are troublesome.
> > > 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.
And? There is a lot of (low quality) SW around, which simply ignore the
defacto existing implications of inter-library dependencies on other
OSes, and expect other OS to provide the same functionalities as Linux
does. libtool only propagates some amount of these packages' bad designs
to Linux, you'd be facing almost anywhere else outside of Linux.
That's why I consider Fedora's conventions on "removing *.la's" NOT
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.
From a practical POV, I can live with package maintainer's
*.la's on Fedora, because they are rarely useful on the "island
Fedora", but changing this into "MUST REMOVE", to me is going waaaay too
From a developer's POV, if YOU think libtool on Linux's
behavior must be
changed to not installing *.la's, I'd propose you to come
up with a
proposal on the libtool lists and try to have libtool changed in