Re: autopkgtest gating migration, nearly there. But ...
(dropping d-release)
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 ? Is that actually just
used to specify the version of the tests to use ? But then there
would only be one of it. Or does it somehow mean `all binaries from
src:2' or something ?
I am really feeling very dim here.
> > 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 ?
> > 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 ?
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.
> > 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.
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. 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.
However, maintainers are exhorted not to declare needs-build (for
ci.d.n capacity reasons).
There is a conflict here between the stated best practice, and the
actual incentives to which maintainers are exposed.
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.
> >> 3) test dependencies generated by autodep8 are fully unknown to the
> >> migration software. It seems (but I haven't verified properly) that e.g.
> >> with r packages the test dependencies can be versioned as well.
> >
> > I don't know much about autodep8. It sounds like maybe autodep8
> > should be a way to automatically maintain or help maintain
> > d/t/control, rather than some post-hoc thing. But I guess everyone
> > hates committing generated files (which this would imply) too much.
>
> One solution could be that indeed instead of running autodep8 from
> autopkgtest, packages should run it while creating the Debian source.
> Apart from committing generated files, another drawback of that is that
> when autodep8 gets enhanced, the adoption rate is much lower. Currently,
> once autodep8 migrates, every package that falls in the enhanced class
> of packages, gets the better test. Image we find a way to test Python
> package better than the current poor man's solution of just importing
> the module that matches the Python package name (there were idea's on
> debian-devel some months ago), we want all Python packages that opted
> for autodep8 to do that (instead of continuing to only test importing
> modules).
Yes. Hrrm.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: