On Thu, 18 Jan 2007 01:08:57 +0100, Axel Thimm wrote:
On Thu, Jan 18, 2007 at 01:10:56AM +0100, Michael Schwendt wrote:
> On Thu, 18 Jan 2007 00:15:10 +0100, Axel Thimm wrote:
> > So let me ask again: What's really that bad about including the
> > current *.la files into devel by default (unless really needed in main
> > packages) other than a couple more dependencies between *-devel
> > packages and how bad are these "bloated" devel interdependencies?
> Unfortunately, the "couple of more dependencies" is visible in the
> BuildRequires tree, too.
Yes, that's what *-devel packages are about.
Dependencies of *-devel packages are about providing all the stuff that is
needed for an API (including any technical requirements for details like
linking). You seem to favour the "bloat" that increases maintenance
requirements for packagers and software developers.
What happens with .la dependencies is that they extend the API and make
the linking more difficult (by pulling in many more libraries as if the
goal were static linking). E.g. the API user of libA-devel suddenly needs
libB-devel although libA's API is independent from libB's. In a different
scenario, the libA-devel user suddenly needs an additional libF-devel,
because libB started using libF. You end up with wrong binary dependencies,
The user of libD-devel may need both extra packages, and when either one is
updated without breaking the ABI, a rebuild of the tree may be needed only
to fix orphaned .la dependencies, e.g. /usr/lib/libF.la in /usr/lib/libB.la,
or changes in .la deps in general.
> It results in pretty much the opposite of trying to eliminate
> superfluous and redundant BR. You will find that packagers will be
> confronted again and again with missing BR which are only needed
> because of direct dependencies between .la files or changes within
> the libtool dep-chain.
And? One BR perhaps (!) too much for one *.la file.
They are _wrong_ BR and wrong R even if you insist on barking up the tree
to get leaf packagers to add the bloat in their packages before you would
be able to rebuild your package fine without starting to use ugly work-arounds.