Bug#752989: libio-callback-perl: FTBFS with Perl 5.20: alternative dependencies

[Niko Tyni]

On Sat, Jun 28, 2014 at 09:41:46AM +0200, Jonas Smedegaard wrote:
> Quoting Niko Tyni (2014-06-28 09:03:08)
> > The problem is this dependency:
> > 
> >   Build-Depends: perl (<< 5.19) | libmodule-build-perl (>= 0.40),
> > 
> > Perhaps something like this (untested) could work?
> > 
> >   Build-Depends: perl (>= 5.17.1~) | libmodule-build-perl (>= 0.40), libmodule-build-perl
> > 
> > (The unversioned dependency would guarantee either a perl version with
> >  the bundled M::B, or a separate package. The versioned alternative
> >  would guarantee that the M::B version is new enough.)
 
> Relying on a (build-)dependency being resolved by a virtual package is 
> not allowed by Policy, with the reasoning that it causes 
> non-deterministic behaviour.

Which policy clause is that?

As a counter example, I see 350 or so source packages in the archive
build depending on libpng-dev, which is a virtual package.

ISTR a recommendation for virtual-package | real-package too, but I can't
easily find it in the policy and it doesn't seem to be used in practice.

The best I can find is this passage in Policy 7.5:

     To specify which of a set of real packages should be the default to
     satisfy a particular dependency on a virtual package, list the real
     package as an alternative before the virtual one.

> libmodule-build-perl exists as a package, so simply favoring that over 
> the perl-provided version should work _and_ be deterministic _and_ work 
> on more relaxed environments permitting undetermnistic fallbacks (read: 
> backporting with pbuilder or variants like cowbuilder):
> 
>   Build-Depends: libmodule-build-perl (>= 0.40) | perl (<< 5.19)

Fine by me, but that allows for perl 5.16 and lower, which have
M::B < 0.40. If that's not a concern, just drop the versioned
part and use plain libmodule-build-perl?
-- 
Niko Tyni   ntyni at debian.org