[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: autopkgtest needs-recommends



Hi Niko,

On 14-06-18 17:51, Niko Tyni wrote:
> Well, '@' is equivalent to 'all binary packages from the same source as
> the test', right? Except that '@' guarantees that the actual packages
> will get installed rather than some others that Provide the same name,
> which we would actually need to happen here so we can look at their
> Recommendations.

But there are a lot of cases where you would not want '@'. E.g. in cases
 where some of these packages conflict and one thus can't use '@' (we
recently had one bug report that had such a case) or in cases where you
just want to have a subset of your own packages to test if they work
independently as described by their own dependency relations. I don't
know if in such a case one would want needs-recommends (I could easily
guess so), but I don't want to exclude that.

So thinking about it, your versioned provides solution is limited to '@'
and tests that don't want to or can't use '@' are still stuck with
potentially the wrong package. I guess that is why $(apt install) does
install the real package, as otherwise there would be no way for the
user to say you don't want the package that provides it, but the real
one. Shouldn't we put all the requested packages (and not just the
synthesized ones) in your second call? Or should we file a bug report
against apt to request an option to force real packages over Providing
packages in case they both exist?

> Re limiting: I always thought (somewhat naively I guess) that
> 'needs-recommends' only means 'the recommendations of the package(s)
> to be tested' rather than 'the recommendations of all the test
> dependencies'. But I see the documentation doesn't really back that,
> and neither does the traditional implementation.

I noted already in the past that I agree with you that that feels like
the better meaning. But than you should (;)) agree with me that it
should not be limited to '@' alone.

> In practice I'd be somewhat surprised if anything relied on the difference.
> That's something that could be tested against the archive I guess. Just
> needs somebody to do the work :)

Full ack.

Paul

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: