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

Niko Tyni ntyni at debian.org
Thu Sep 11 19:18:51 UTC 2014


(Replying once more, but thanks again for fixing this!)

On Thu, Sep 11, 2014 at 07:47:39AM +0200, Martin Pitt wrote:
> Niko Tyni [2014-09-10 23:23 +0300]:

> > Inserting an explicit 'apt-get install <package>' invocation should pull
> > in the separate package even if it's already provided AFAICS?
> 
> If that will ignore provides, then that would be a plausible way for
> the '@' part. adt-run would then need to resolve architectures by
> itself, though.  

It certainly does ignore provides. I don't quite understand what
you mean about resolving architectures. Are there situations where
installing the "native" architecture version of the package wouldn't
be the right thing to do?

> And we still need the adt-satdep dummy package / -f
> install trick to install all the other test dependencies, as they can
> contain arbitrarily complex constructions of alternatives,
> architectures, version constraints, etc. I really want to avoid
> reimplementing half of apt's resolver in autopkgtest :-)

Sure, I see why adt-satdep is needed and it's a nice solution.
@ just looks like an exception which deserves special handling.
 
> I think I'll keep that idea on the shelf for now. I've heard Michael
> Vogt talk about some possible improvements in apt to make it easier to
> install local debs etc., so perhaps by the time we get versioned
> provides (if we get them), apt will make this easier for us.

Fine by me of course. Please note that I've just filed #761219 against
debian-policy about versioned provides. You might want to voice any
concerns you have about the concept there.

Thanks for your work,
-- 
Niko Tyni   ntyni at debian.org



More information about the autopkgtest-devel mailing list