Hi, Le dimanche 02 décembre 2007 à 17:11 +0100, Loïc Minier a écrit : > An idea that came up is to use a per-dependent package information > provided by the maintainer such as the build-deps version [2]. It > would require a map from deps to build-deps and could typically be > combined with the existing systems to inject a dependency >= > max(shlibdeps version, bdeps version).
I like it, and I also think it would be the opportunity to go further in
the direction of dependency automation.
Currently, many upstreams use pkg-config to specify their build
dependencies, and it is, regardless of other issues, a good system that
we should promote towards upstream developers. We could build on
pkg-config and replace it, during the build, by a wrapper that dumps
some information in a build-specific place when the call is successful.
Let’s say that the upstream configure.ac specifies the following:
PKG_CHECK_MODULES (FOO, x11 >= 1.0.2
gtk+2.0 >= 2.8
gconf >= 2.0)
And the source package specifies:
Build-Depends: libx11-dev (>= 2:1.0), libgtk2.0-dev (>= 2.10), libgconf2-dev
(>= 2.0)
Every successful call to pkg-config would fill in a file, let’s say
debian/pkgconfig.deps, that would in the end contain:
# pkgconfig_file required_version dev_package shared_package
version
x11 1.0.2 libx11-dev libx11-6 2:1.0.3-7
gtk+2.0 2.8 libgtk2.0-dev libgtk2.0-0 2.12.2-1
gconf 2.0 libgconf2-dev libgconf2-4 2.20.1-1
(The package version is needed because you need to extract epochs.)
In the end, shlibs generation would be able to generate the correct
dependency, based on the highest of the three versions:
1. the version required by upstream;
2. the version required by the build-deps;
3. the version generated by the symbols file.
Plus, in this specific case, it would make the build fail because the
Debian maintainer has forgotten to bump the libx11-dev build-dependency
to 2:1.0.2, which is deadly useful information.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
