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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org