Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[David Leverton]

On 5 October 2010 02:55, Diego Elio Pettenò <flameeyes@×××××.com> wrote:
> USE flags add complexity, and in real use cases there are near to no
> good reasons at all to keep .la files around.

That's why I initially suggested a variable rather than a USE flag, as
if it was implemented in a centralised function it wouldn't add
complexity to individual packages (no need to declare it in IUSE, for
example).  Although the USE flag approach has advantages too, as has
been mentioned.

> Also, I would like to ask again that if you're going to argue "you never
> know who might use them", you're going to have to actually understand
> _what_ the files are used for, _which_ software uses them, and come up
> with a use case for them, not a vague "oh there might be a project that
> use them".

The fact is that you /don't/ know what might use them.  Gentoo is a
general-purpose system, you can't predict what people will want to do
with it, including use software that relies on .la files from
libraries in the tree.  Obviously you can't support everything that
anyone might conceivably dream up, but keeping packages compatible
with their upstream state is a good place to start.

> Things like "taking in account what isn't in the tree" (without actually
> having a clue on what .la files are for)

So taking into account what isn't in the tree while knowing what .la
files are for is OK?

> looking for "alternative approaches" (to do what, exactly?)

Alternative approaches to fix the excessive dependency propagation
without breaking the semantics of libtool under static linking etc.

> Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does
> not explicitly provide it (it's a byproduct of libtool)

What's the difference?

> and they don'trequire/ask to rely on it (otherwise it wouldn't
> provide pkg-config or .pc files).

pkg-config is useful because it's a standardised way to check for the
presence of other packages, including specific versions if necessary,
and to get the necessary include and library paths to use the library
- it's not the case that pkg-config is only supported for the sake of
avoiding libtool.  pkg-config /also/ overlaps with some functionality
of libtool, but that's not to say that no-one must ever use the
libtool functionality.