Re: dh_libtool proposal (-dev dependencies on -dev from libtool)

[Kurt Roeckx <kurt@roeckx.be>]

On Wed, Oct 05, 2005 at 05:44:02PM -0400, Jay Berkenbilt wrote:
> 
> The proposal is to have this program populate a substvar named
> ${libtool:Depends}.  I've studied this problem at a cursory level, and
> this is what I currently intend to do:
> 
>  * Traverse the directory to be installed for .la files
> 
>  * Parse the .la file to read dependency_libs item; scan this item for
>    other .la files
> 
>  * Determine what packages provide the given .la files
> 
>  * Filter out packages that are already in the dependency list
> 
>  * Place the resulting packages in the libtool:Depends substitution
>    variable

I think it shouldn't add anything that isn't also in the
Build-Depends for the package itself.

But I'm not really in favour of this at all.  I think we should
rather concentrate on avoiding the need to have those
depedencies in most cases.

Some things I think about:
- It shouldn't be using the dependency_libs in most cases on
  atleast Linux in the first place when creating shared libraries.
  In that case, there shouldn't even be a reason to parse that
  line.  The current Debian version is patched not to link to
  those libs, but it still parses that line anyway.

  Upstream is looking into a better fix for the whole dependency
  problem when linking, and it might be nice to fix that too.

- There was talk about libtool dealing with missing .la files.  I
  don't see how this would work.  If you're trying to link
  staticly, it will need that file, for shared see above.

  What we could try and do is reduce the libraries that are in
  the dependency_libs field.  For instance on Linux, when we only
  provide a shared lib, it's not needed to have anything in the
  dependency_libs.

- Something else I wonder about is wether it currently works
  recursivly or not, I would need to check the code.  If it did,
  we can probably also reduce the number of libraries in the
  dependency_libs for the general case.  It now atleast has a
  list of all libs it will end up linking to, even for indirect
  dependencies.  It really should only list the direct
  dependencies.

  This would also make it so much easier to change some
  dependency at a lower level, and we don't have to go and relink
  all the libraries like we for instance had to do in case howl
  was removed from main.
  

Anyway, it would be great to get all those things in a new
upstream libtool version.


Kurt