(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 [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
