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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
