This is an informal proposal for a dh_libtool program which I was
considering implementing over the next few days. I'm not so sure
though after reading bug 192008, so I thought I'd bring it up here and
see if there's any kind of consensus.
Basic problem: -dev packages for packages that use libtool need to
have runtime dependencies on the -dev packages that provide the .la
files that they need at link time.
Basic proposal: provide dh_libtool to automate this. Note that this
is called dh_libtool and not something more general to make it clear
that it is addressing only the subset of the general problem that
directly relates to libtool. This seems like a normal enough case to
require a special case even if that special case doesn't fully solve
the entire problem.
Objections raised in 192008: this solution misses several cases
including multiple -dev packages providing the same library and
packages that don't use libtool. Joey Hess raises objections very
clearly in his response to bug 192008, and I find them convincing,
though sometimes we may fail to provide a solution that's good in many
cases because it isn't good in all the cases we can think about. I'm
not convinced that this tool couldn't still be useful as long as its
limitations are understood.
Details:
In late July, there was a thread on debian-devel about handling -dev
packages' dependencies on other -dev packages as required by libtool
among other things. (Subject: "SUMMARY: Re: shared library -dev
package naming proposal") The thread discussed various aspects of
libtool brokenness, but regardless of any of that, I had suggested
that we have a program that could populate these dependencies
automatically by parsing .la files, and various participants liked the
idea. I had intended to implement this program during some time off I
have between jobs. I'm now in that time off period and intend to work
on this over the next few days.
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
This would, like other debhelper tools, take various arguments to
control which package is being scanned and to control other aspects of
the behavior that should be configurable. I will also study
dh_shlibdeps and dpkg-shlibdeps to make sure that I'm not leaving
anything out that's important.
For the initial version, I will not "overdesign" this with anything
analogous to shlibs files, though it would probably be important to at
least support local overrides in case a .la file is provided by more
than one package and the packager wishes to specify a specific
dependency on one other than the one that is installed. (This case
would not be covered by simply excluding existing explicit
dependencies.) If this catches on and libtool isn't fixed to make it
unnecessary, then some additional infrastructure support analogous to
shlibs files could be added. In the mean time, versioned dependencies
on other -dev packages can be listed explicitly or handled in local
overrides, even though this has the unfortunate property of requiring
the packager of the dependent package to keep track rather than the
packager of the package that provides the lower .la file.
For testing purposes, I would create a native package called
dh-libtool that I would probably just put in my people.debian.org
area. If people decide that this is a useful item, it should
presumably be included as part of debhelper and also invoked from
debhelper.mk in cdbs. (Other builder helpers that invoke debhelper
could also be modified as needed, of course.) In that case, I would
suggest it to the debhelper maintainers.
There's actually a proof of concept script written by Michael Dänzer
posted to bug 192008 (which I saw after writing all of the above) that
could be a good starting place if this is actually worth pursuing.
Comments? If there's no consensus, I'll probably abandon this project
and just use a script to help me do it by hand when I need to do this.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
