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

[Ralf Wildenhues]

Hi Kurt,

Sorry for the delay, and for the quick writeup, too.

* Kurt Roeckx wrote on Wed, Dec 07, 2005 at 07:40:53PM CET:
> 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

Good idea.

> (until you drop support for older versions?)

Probably a while longer, but yes, in principle.

> 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.

ACK.

> > - 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.

Yes, they /should/.  We agree on this.

> 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.

Hmm.  Maybe the problem isn't as bad nowadays as it was a while ago.
There used to be some packages that did not properly list all their
dependencies.  At least some people mentioned that concern last time
this issue was brought up.

This is the requirement that I think is easiest to lift in the Debian
version: your packages are generally in pretty good shape (or will be,
when we're through with this).  Having pushed that upstream, chances
will be much lower that there will be remaining trouble packages.

> > 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.

Right.

> 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.

Agreed.  I'm saying Debian here only because I know
- your packages are generally in good shape, because
- you have experience through link_all_deplibs=no

not because I have a desire to special-case them.  All special-casing
there is would *only* be for moving from link_all_deplibs=no to the
desired way, *without* having such a thing as a flag day, and any such
special-casing should probably be applied to Debian's libtool only.
OK?

> 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.

Agreed as well.

> > > 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?

No.

> Afaik, this doesn't work.

Right.

I mean: in huge package trees, people sometimes rely on the fact that
libtool will link them with all they need, because they link against all
that, too.  

> > 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.

(I'll try to explain what I meant when I have more time; sorry).

> > 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.

FWIW, yes, I'd consider it broken, too.  Tell that a C++ user though.

> 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.

And that's why, in general, we may need to know about this.  Say,
libfoo and libbar are both built by the same package, but there is an
installed version of libbar, which provides a different bar() symbol.
For the sake of the argument, let's assume it's versioned, and the
version of the uninstalled one is different than the installed one.

If we don't follow and link P (which links against libfoo) also against
libbar, it will simply be broken.

Cheers,
Ralf