Bug#761003: autopkgtest: @ shouldn't be satisfied by a virtual package

[Niko Tyni]

On Wed, Sep 10, 2014 at 09:16:42PM +0200, Martin Pitt wrote:
> Niko Tyni [2014-09-10 17:23 +0300]:
> > Thanks for the fix! However, please note that this implementation will
> > most probably break again with versioned provides, which we hope to start
> > using after jessie as they are a neat solution to certain other long
> > standing issues around the perl package.  So perl-modules will Provide:
> > libhttp-tiny-perl (= 0.043) which satisfies the (>= 0~) dependency.
> 
> Yes, I'm aware it's not ideal, but it's at least better than no
> version at all. But I don't have a better idea, I'm afraid: it's not
> generally possible to predict the version number of the binary
> packages from the source package version. debian/rules might modify
> the binary version (add or remove epochs or do other modifications),
> there are binNMUs, etc. Perhaps we can figure out a heuristics which
> is safe and avoids most of these wrong cases of catching a versioned
> Provides:.

The dependencies seem to be currently satisfied by something like
 [generate a dummy package with the right dependencies]
 dpkg --unpack dummy package
 apt-get -f install

Inserting an explicit 'apt-get install <package>' invocation should pull
in the separate package even if it's already provided AFAICS?

> (Aside from that I think that versioned Provides: are madness, but I
> suppose this was discussed long and thoroughly :) ).

I'm not aware of such discussions, but I expect we're going to need
a policy discussion before they are blessed. They were implemented
quite recently in dpkg and apt.
-- 
Niko Tyni   ntyni at debian.org