Re: Reducing dependency_libs to what was on the command line.

[Kurt Roeckx]

On Wed, Dec 07, 2005 at 10:41:47AM +0100, Ralf Wildenhues wrote:
> 
> Not if you have to deal with installations lacking .la files.
> 
> Really: The only sane way we can get this done without breaking
> backward compatibility and retain user-expected behavior is if we

Yes, one problem is that users who have a version that
doesn't walk the dependencies properly, it might not work as
expected, and this would be a problem if I'm using an older
version and try to link to a library that is created with a newer
version.

So how do you feel about adding a new field that only lists the
direct dependencies, and keep the old one around for a while
(until you drop support for older versions?) containing both the
direct and indirect?  The newer versions could then only use the
new field if it's present and fall back to the old if it's not.
It's currently the only option I see to make it backward
compatible.

> - implement the walking and all that stuff
> - make library authors be aware
>   (ie. they need to state, maybe with a command line switch: I
>    have listed all my direct dependencies)

I'm not sure how I feel about requiring authors to do that.  They
should always link to all their direct dependencies.

I think I need an example of where you think there can be a
problem, because afaik, there shouldn't be any problem.  And if
you find an example, I'm guessing it doesn't work portabily now
either.

> And also get all of this in a way that Debian can still upgrade
> gradually from their current set to the new.  I believe it is possible.
> For example, if we allow arguments from some environment variable,
> or some other debian-build global setting.  Would you agree with this?

The only way I can see this working would be to have an
environment variable.  Note that there is no such thing as a
global setting, each package will have to manually set that
variable (in the debian/rules file).  But that shouldn't be a
problem since people already have to re-libtoolize the package to
get the desired behaviour anyway.

Anyway, I'm not really interested in things that only benefit
Debian.  Everybody should be able to benefit from what we're
doing.  And I believe this is also in the spirit of our Social
Contract.

What this reduction of the dependencies is mostly about is not
reducing the dependency tree, it should not have any effect on
it, but our ability to change the dependency tree.  But I feel
this is getting a little bit off topic.  If someone is interested
in what is involved, feel free to ask though.

> > > Well.  If people link convenience archives directly in programs
> > > (which they shouldn't, but they do), then this patch will break it.
> > > 
> > > You also need to take into account that quite a few users
> > > - either don't install the .la files (which we may rightfully,
> > >   declare as "it's their problem then", but in reality that will
> > >   be another maintenance nightmare)
> > 
> > If the .la file isn't installed, it doesn't matter what is in it.
> 
> But, on some systems, the library we just compile *will need* to link
> against all other libraries.  That means, for package authors, they
> may need to take into account that they can't rely on installed .la
> files taking this burden off of them.  Even with the non-transitive
> dependency_libs, all libs may need to be listed.

You mean that some people had a .la file at some point, but don't
keep it around?  Afaik, this doesn't work.

If you have a libA linked to libB, libA's .la file mentions
either libB's .la file, or -lB.  To not make this example too
hard, let's just assume it has libB.la in it.

Now if I want to link something to libA, and libB.la doesn't
exist, libtool will complain that it can't find libB.la and fail.
I've seen this way too many times that it failed.

In case there never was a libB.la, libA.la will just mention -lB,
and there isn't a problem either.

Once a .la file exists, it's hard to remove it without breaking
something.

> Besides, you're missing the point here: just because the installed
> system does not use .la files, doesn't mean a user that happens to
> install below $HOME does not want to use it.

I'm really not following.

> And back when the deplibs stuff was discussed (about a year ago) before,
> there was another item that came up: Do we want to support the notion of
> exposure?  I.e., a header accompanying my library libfoo, foo.h, has
>   static inline foo () { return bar(); }
> where bar is from libbar.  Even if a user of libfoo believes not to use
> libbar directly (after all, only public interfaces of foo are used), it
> will be necessary to link against it.

I consider this broken, but unfortuantly it happens way too much.

Anyway, I disagree that it should link to it.  The reason you
think you should link to it is because you're using a symbol from
bar.  But bar is clearly part of foo's API, and in case bar
changes the API in such a way that it breaks something linked to
foo, both of their API's changed and both of them should do an
soname change (or equivalent).  Adding a link to bar doesn't buy
you anything, since you'll have to relink everything anyway.

Anyway, in case of the gnu linker, it has this feature, that I
dislike, that it goes and add a DT_NEEDED for bar too in case you
only link to foo.


Kurt