Re: Build-Depends and virtual packages
On Tue, Apr 24, 2007 at 02:57:40PM +0100, Regis Boudin wrote:
> Over the last few days, I've been looking at Build-Depends and
> Build-Depends-Indep fields. My original aim was something like trying to
> have a build path to rebuild the complete archive, with only a Sources
> file as starting data (basically, src:foo build-depends on libbar-dev in
> the "Binary" field from src:bar means src:foo depends on src:bar).
> I ended up with quite a large number(around 700) of build-depends on
> packages not listed as binary. The large majority of these are the result
> of transitions, with the new binary package providing the old one. The
> most common cases are build-dependencies on libncurses-dev, libz-dev or
> the various libpng*-dev.
> Basically, that's the same sort of test as the lintian
> virtual-package-depends-without-real-package-depends warning, except
> lintian only checks against the authoritative list of virtual packages,
> where what I have checks for build-deps (and only build-deps) on anything
> that is not an actual binary package.
> Also, the checks give separate results for Build-Depends and
> Build-Depends-Indep and are for a given arch. So, if a package
> "Architecture : all" build-depends on one "Architecture : sparc", it will
> complain for the other arches. Obviously, if an alternative depency is
> against a real package, it s considered as ok.
> I have results I will put online as soon as I convert them in a better
> format than a simple text list, but if you have comments on what to do
> with this list, they are more than welcome.
In the general case: nothing. It is *not* correct to turn this into an
alternative Build-Depends: real-package | virtual package, because sbuild
will only look at the first branch of any or'ed build-dep. If the virtual
package is the stable name for the -dev interface, that's what packages
should be build-depending on.
The reason depending on a virtual package without first listing a real
package is considered a bug is that it gives undefined behavior in the
selection of a package when there is more than one package providing the
named virtual package. But there are cases where depending on the virtual
package alone is still correct -- e.g., apt Provides:
libapt-pkg-libc6.3-6-3.11, which is the right virtual package to depend on
when using libapt. The same applies to build-deps on virtual packages,
which normally are provided by only one real package at a time in a given
suite.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: