Build-Depends: some-virtual-package (not stating any real package)

[Colin Watson]

On Tue, Jul 17, 2007 at 11:00:12AM +0100, Ian Jackson wrote:
> acpi 0.09-3 says this:
>  Build-Depends: debhelper (>= 4), automaken, autoconf, \
>                 help2man, dpkg-dev (>= 1.9.0)
> (linebreak mine).
> 
> automaken is only a virtual package.  My recollection was that this
> was discouraged by Debian policy, and that instead a real package
> should be offered as an earlier alternative.  However, the current
> version of Debian policy s7.4 says this:
>   If you want to specify which of a set of real packages should be the
>   default to satisfy a particular dependency on a virtual package, you
>   should list the real package as an alternative before the virtual
>   one.
> 
> This does not clearly imply the requirement that I and mvo thought
> existed.  acpi builds fine with sbuild (obviously) but both apt-get
> build-dep and the machinery used by autopkgtest fail.

I had the same understanding, and I note that the Lintian authors also
mark this as a bad idea (though not an out-and-out error):

Tag: virtual-package-depends-without-real-package-depends
Type: warning
Info: The package declares a depends on a virtual package without listing a
 real package as an alternative first.
 .
 If this package could ever be a build dependency, it should list a real
 package as the first alternative to any virtual package in its Depends.
 Otherwise, the build daemons will not be able to provide a consistent
 build environment.
 .
 If it will never be a build dependency, this isn't necessary, but you may
 want to consider doing so anyway if there is a real package providing
 that virtual package that most users will want to use.

Wording notwithstanding, this check is actually applied to Build-Depends
and Build-Depends-Indep too, although it doesn't know about automaken as
a virtual package. I've fixed this for the next release of Lintian. The
packages I can find with this error are (E&OE):

  acpi
  atris
  frox
  ghostscript
  icecast-server (I think; actually lists the real package second!)
  jd
  mol-drivers-linux
  time
  zipios++

> Is the policy inadequate ?  If so then policy should be fixed in
> Debian and acpi needs a fix too.

FWIW the first reference I could find to this paragraph of policy is:

  http://lists.debian.org/debian-policy/1999/01/msg00120.html

That didn't even introduce that wording, merely corrected the grammar,
so it's clearly very old.

> If policy is correct then gdebi (used by autopkgtest) and
> apt-get build-dep need to be fixed to permit this case.

I think this would be a good idea in any event.

I'm curious as to whether gdebi / apt-get build-dep handle the case
where the target source package build-depends on a package which in turn
depends on a virtual package without a real alternative. If policy ought
to be changed, that might influence whether it should be changed just
for build-dependencies or for all packages.

> Another possible interpretation is that `in Ubuntu we always want the
> Build-Depends to specify which real package to use, so that builds are
> predictable'.

For the sake of getting on with autopkgtest deployment, this seems a
reasonable thing to enforce in Ubuntu at least for build-dependencies.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]