On 30/07/2022 16:45, Paul Gevers wrote:
Control: reopen -1
Control: retitle -1 britney recursive installability test in autopkgtest
Hi Yadd,
On 30-07-2022 15:58, Yadd wrote:
Node.js isn't available on armel, and the consequence will be to not
fix some CVEs/BTS during freeze. Hope none of them will appear...
For those we have unblock requests and the normal process to get
packages into testing during the freeze. The autopkgtest process wasn't
designed to change that.
Maybe Britney could not consider autopkgtest as failing when a build
dependency is missing in one arch (at least for arch=all) ?
Why *build* dependencies?
britney takes dependencies into account and doesn't schedule the jobs if
all binaries are uninstallable. However, looking at your example, there
might be an issue that it doesn't resolve that recursively during the
policy phase of britney. (There's also a problem for britney that
involves source packages that build both arch:all and arch:any binaries,
which it fundamentally can't always resolve correctly, I thought we were
in that case here). Let's see if I can come up with a reproducer in our
test suite.
Thanks!
Most of node-* package build depends on nodejs but are usable without
it. See libjs-bootstrap4 for example
Again, what do build dependencies have to do with the problem? If they
don't need nodejs to run, they shouldn't have a dependency on them and
everything is fine. You'll recall that I recently stripped the unneeded
nodejs dependency from all node-d3-* packages. Now they are installable
on armel.
Paul
By "build dependencies", I meant "test dependencies" (Build-Depends
contains often both). All JS test framework needs nodejs (mocha, jest,
tape,...) and all node-d3-* autopkgtests will fail with armel.
Cheers,
Yadd
