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

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

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

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