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

Re: autopkgtest needs-recommends



On Fri, Jun 15, 2018 at 11:16:04AM +0200, Paul Gevers wrote:

> 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?

I agree this discrepancy between handling '@' vs. 'manually listed binary
package(s) built from the source package we're testing' is a potential
problem. Although '@' has been treated specially wrt. to unversioned
Provides since 2014 (#761003), the '(>= 0~)' hack was possible for
manually listed dependencies too until versioned Provides came along,
so this is a new(ish) issue.

I think the special handling that we have now should probably be extended
to fix this discrepancy, but I don't think it should affect all of the
test dependencies. It seems to me that the intimate connection between the
source package that has the tests, and the binary packages generated from
it, is the reason that this special handling is needed in the first place.

> > 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.

I agree :) But I think that if we make these test dependencies (= those
that are built from the source package under test) special, they should
also get the special handling wrt. Provides.
-- 
Niko



Reply to: