On Thursday 20 April 2017, Bernhard Voelker wrote:
On 04/20/2017 01:30 PM, Ruediger Meier wrote:
This is a nice idea but it has a few drawbacks: 1.A bad coreutils-testsuite does not seem to prevent automatically that the coreutils package would be released to the users.
there is still the package maintainer who is repsonsible for forwarding packages ... so I don't see this danger.
2.coreutils-testsuite is not testing the *same* binaries which we install finally in the distro. Bugs or inconsistencies in OSB or rpm could cause that "coreutils" builds broken binaries but "coreutils-testsuite" looks ok.
That's a valid point though ...
What I would really like is that project's like coreutils would have a "make check*" target which runs tests against the installed coreutils.
... it has been like that for quite a while now. I don't know what was the motivation behind the split, but I can imagine that this speeded up the build cycles on OBS dramatically.
Yes, the non-testsuite package has less "BuildRequires" to prevent "unnecessary" rebuilds. But different "BuildRequires" even increases the probability that the installed and tested binaries could differ.
IHMO our OBS bootstrapping way to rebuild again and again until everything converges to reproducable packages is bad especially when we add such "build cycle optimizations". It makes spec files and tests very ugly, complicated or even unsafe (e.g. util-linux). It's also a pain to review submit requests for such packages having duplicated spec files and changelogs.
Thus said, I'm not against removing 'coreutils-testsuite'. Maybe it'd be an improvement if only the smaller (faster) 'make check' is run for the coreutils package while it would run the slower 'make check-very-expensive' tests in the coreutils-testsuite case.
Have a nice day, Berny