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