Re: optional package in Build-Depends (how?)
Dmitry Smirnov <onlyjob@member.fsf.org> writes:
> It makes perfect sense for complete (working) test suits.
> I had an experience with valgrind only recently when upstream introduced
> yet-to-be completed tests which are failing everywhere so far.
> I'm already ignoring tests failure using override
> override_dh_auto_test:
> -dh_auto_test
> In which case it makes perfect sense not to take the risk of FTBFS on some
> architectures for the sake of testing which is not even useful yet.
Oh, okay, yes, if you're already ignoring errors from the test, then I'd
only build-depend on valgrind where you want to see the results in the
build logs for further work.
> Another package I was recently testing on GNU Hurd where some tests were
> failing (even though the package is working).
A bug in the test suite? It's worth being careful about assuming that the
package is working when the tests are failing. :)
> So again I had to ignore post-build test(s) failure.
I don't think that makes sense to do for Hurd, actually. The package
needs to be ported to it; I would let the build fail until that's
happened. That may mean just porting the test suite or the test suite may
be uncovering a real issue. That's generally what I do with any
non-release architecture until I have time to do the (low priority,
usually) porting work. You don't want to accidentally hide failures that
need porting effort by making the build succeed "artificially."
> Testing still useful to me when I read build logs, but I'm very
> reluctant to introduce a potential failure point with dependency more
> strict than necessary.
Making the *dependency* strict isn't going to add a failure point. It's
not like valgrind is going to disappear on i386 and amd64.
> While I'm with you and I fully share the desire not to allow skipping
> tests on i386 or amd64, I think risk of FTBFS outweighs it. You see,
> When I build the package on my amd64 host I will likely to notice if
> something goes wrong but my concern is more about architectures I have
> no access to. I'm not yet in habit of reading all build logs from all
> architectures upon package upload when the build was successful.
You will generally get mail if the build fails.
If the build failures are mostly due to bugs in the test suite, I agree
with you. That's the criteria on which I'd make the decision. If the
tests are finding bugs, then the failures are valuable and shouldn't be
suppressed.
> And it appears to me that if tests failure is already pretty much
> ignored is would be acceptable to make tests optional with weak build
> dependency.
However, Debian quite intentionally does not have such a thing as a weak
build dependency, nor do I think such a thing is appropriate here.
Rather, I think you should make a decision: either depend on the tools
required to run the tests and ignore the test failures (if you think
they're bugs in the test suite and not the package) if the output is
valuable, or don't depend on the tools and skip the tests.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: