Hi Ian,
On 18-09-18 14:17, Ian Jackson wrote:
> (dropping d-release)
hmm
> Paul Gevers writes ("Re: autopkgtest gating migration, nearly there. But ..."):
>> On 17-09-18 15:52, Ian Jackson wrote:
>>> IIRC previously [the test request information from britney2 to
>>> ci.d.n] was simply
>>> ('please run this in testing', <package>, <version_in_unstable>)
>>> for each proposed migration.
>>
>> It's slightly more, ('run this in testing', <package>, <with the
>> following from from unstable: src:1, bin_pkg2, src:2>)
>
> What does ci.d.n do with the src: information ?
It passes it on to autopkgtest. autopkgtest uses this to set up apt
pinning for every package in that line. E.g. all binary packages from
src:1 and from src:2 and the binary package called bin_pkg2 will be from
unstable if the are to be installed. All other binaries are from testing.
> Is that actually just
> used to specify the version of the tests to use ?
Not the version, but the suite they are taken from.
> But then there
> would only be one of it. Or does it somehow mean `all binaries from
> src:2' or something ?
That.
> I am really feeling very dim here.
Sorry.
>>> Now it is ... what ?
>>
>> The same. So, what I meant above was that I britney started to extend
>> the list from "src:1", to "src:1, src:2, src:3" if binaries from src:2
>> and src:3 are needed to satisfy dependencies of the test of package with
>> binaries from src:1 from unstable. E.g. because the binaries of src:1
>> have a versioned dependency or because binaries of src:1 have a
>> versioned breaks or conflicts relation with the test dependencies from
>> package. What changed in autopkgtest is that I disabled (on the Debian
>> infrastructure) the apt-get fall back where everything from unstable
>> would be allowed.
>
> That seems to imply that ci.d.n is searching Packages.xz for the
> Source line and generating apt preferences to pin all the
> corresponding binaries to unstable ?
I can't remember if it is from Packages.xz, but yes.
>>> AIUI what you mean here is this:
>>>
>>> * T has tests which Depend on @builddeps@
>>> * T Build-Depends B
>>> * The test trigger machinery in Britney (and upstream of Britney
>>> that calculates Testsuite-Triggers) does not understand that this
>>> means that T Test-Depends B.
>>
>> Indeed, because in the current data processed by britney this knowledge
>> is lost.
>>
>>> * Consequently proposed migration of B might not involve
>>> a rerun of the tests for T with the new B
>>
>> This is indeed an issue, but not the one I am discussing here. What I
>> mean is that britney doesn't know that it needs to check if binaries
>> >from src:1 break/conflict the versions of B in testing, while the
>> version of B from unstable would be OK (recursively).
>
> What is src;1 in this answer ? Do you mean what I called T ?
If it is T that comes from unstable because it also was the trigger,
than yes. If the trigger was a different package then no.
> I'm not sure why the version of B in testing is relevant. In my
> example scenario, we would be considering a migration of B, so the
> relevant version of B is that from unstable.
Aha, right, so the answer is no, src:1 is B in your example. Well, and
not even that because currently, unless explicitly specified, we don't
trigger on build depends yet.
>>> I am reminded of this:
>>>
>>> If you declare tests with the needs-build restriction, you will block
>>> the migration of your build-deps when they make your package FTBFS.
>>> But declaring needs-build is said to be undesirable. There is an
>>> obvious anomaly here.
>>>
>>> The anomaly I describe above seems similar.
>>
>> It's not totally clear to me what you are getting at.
>
> I was considering the anomaly I described earlier like this:
>
> * Consequently proposed migration of B might not involve
> a rerun of the tests for T with the new B
>
> This anomaly is a situation where T's tests should in principle be
> rerun due to updates of T's build dependency B, but they are not.
Ack. But if my original question is properly answered, this can
trivially be fixed. My problem is that britney doesn't know it for a
different purpose, but once britney knows, we can trigger on it.
> There is another anomaly, or if you prefer, a paradox. That is as
> follows:
>
> If T declares needs-build, then (I assume) any update of its
> build-dependency B will trigger T's tests.
Not yet, britney doesn't know "needs-build"
> If the new B breaks the
> build of T, that is detected as a test regression. From the point of
> view of T's maintainer, this is desirable, as it prevents a change
> from migrating which causes their package to FTBFS.
Ack.
> However, maintainers are exhorted not to declare needs-build (for
> ci.d.n capacity reasons).
Yes, but also because we want to test AS-INSTALLED packages. Having a
build is OK if it needed to build the test suite, but should not be used
to just have archive rebuilding tests. NOT YET, this may come, but I
prefer to first trigger on indirect dependencies before I want to
trigger all builds.
> There is a conflict here between the stated best practice, and the
> actual incentives to which maintainers are exposed.
Ack.
> These two anomalies are related: both of them are about the
> relationship between T's tests and updates of its build-dependency B.
>
> I reasoned: If the second anomaly is tolerable, maybe so is the first.
> You now say that my first anomaly wasn't the issue you were trying to
> discuss, so I assume you also think that my first anomaly is
> tolerable.
My issue is that IF a test requires a rebuild, than britney should know
because it may need to enable ci.d.n to get the right build depends from
unstable. That doesn't mean I want more builds, it's just that some
autopkgtest require them.
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature