Re: Injecting versions of build-deps in the deps
On Fri, Dec 07, 2007, Colin Watson wrote:
> I wonder if the objections raised to this suggestion could be addressed
> by making it optional in some way - perhaps either by requiring it to be
> manually enabled for each library by some kind of shlibs/symbols-like
> system, or by providing support for libraries to declare themselves
> exempt from it.
I do imagine it wont be mandatory (or useful) for all libs as well and
I agree it should be added on a per package basis; one idea I
mentionned to Raphaël is to extend the shlibs / symbols system to allow
a syntax meaning "Take the build-dep version" instead of having a fixed
version; that is, instead of:
libgtk-x11-2.0 0 libgtk2.0-0 (>= 2.12.0)
we might have some macros like:
libgtk-x11-2.0 0 libgtk2.0-0 (>= $Build-Depends{libgtk2.0-dev})
Can be seen as "dynamic shlibs" or "shlibs macros". (Or symbols.)
[ NB: this is overly simplistic as a package can have duplicate
build-depends like libgtk2.0-dev >= 1, libgtk2.0-dev >= 2, or
libgtk2.0-dev << foo, and there are build-conflicts and
build-deps-indep as well ]
In the last week, I came up with many crackful ideas which most people
should ignore for the time being, but which some will find funny:
instead of defining a complex syntax, we could as well allow for
dpkg-shlibdeps to be extended to call some hook when a particular
SONAME dep is encounted. Some kind of plugins mechanisms to allow some
specialized code provided by the libfoo maintainer to be run when a
libfoo dep is encountered.
This code could be based on API provided by dpkg-shlibdeps for most
things. The plugin interface could be as simple as:
onShlibDep($needed, $pathname) {};
with libgtk2.0-dev declaring in shlibs:
libgdk-x11-2.0 0 run:gtk-shlibdep
or:
dynshlibs: libgdk-x11-2.0 0 gtk-shlibdep
implemented as:
onShlibDep($nedeed, $package, $pathname) {
my $ver = getBuildDepsVer("libgtk2.0-dev");
addDepends($package, "libgtk2.0-0 (>= $ver)");
};
Concrete advantage over the non-crackful idea? I guess none at the
moment, but yours to imagine!
--
Loïc Minier
Reply to: