Re: Source package without a binary
Joachim Breitner <nomeata@debian.org> writes:
> Dear devel,
>
> I have an interesting case for a hypothetical â??source package without
> binary packagesâ??: The haskell compiler comes with an extensive test
> suite. This test suite
> 1. is distributed separately from the sources,
> 2. takes a long time to run and
> 3. partly depends on libraries that do not come with the compiler
> packages, and which in turn Build-Depend on the compiler.
>
> Now point 1 could be solved with dpkgâ??s multi-tarball-feature, and point
> 2 is also somewhat minor (but not irrelevant, compiling GHC already
> takes more than a day on weak architectures, delaying this further is
> undesireable), but point 3 clearly prevents running the test suite
> during the build of the GHC package itself.
>
> From my point of view, it seems desirable to package the testsuite as a
> source-package of its own, build-depending on GHC and the additional
> libraries required, and upload that. Our autobuilding infrastructure
> would thus run the testsuite on the various architectures, which is very
> desirable, given that we are talking about a compiler that is not
> well-tested by upstream on the more exotic architectures.
>
> Theoretically, there is no interesting binary package produced from this
> source package and it seems that the policy does not explicitly require
> that a source package produces binary packages... but I am certain that
> this is an assumption buried deep within so many parts of our
> infrastructure that it is not a good idea to actually try this.
>
> So the logical conclusion is to build a binary package from the source
> that contains nothing (or maybe a log of the test results) and clearly
> states in its description that there is no point in installing this
> binary package.
>
> Is this something that we want to allow? If not, how else should I
> proceed? And are there developers who think that having a source package
> without binary package is a good way to stress-test our infrastructure
> for corner-case-bugs? :-)
>
> Greetings,
> Joachim
I think you could make the binary package be interesting:
1) run the tests during build and include the results
2) include the test suite to be run on the users system
3) provide a little script to run the test suite and to compare the
results with the results generated by the buildd.
Use cases for this package would be to stress test your system and for
testing patches to the compiler or libraries to check for regressions.
For it to be truely usefull it would be important to know about the
expected behaviour. Some tests could be expected to fail on arm for
example while they work on amd64 and so on and to be able to only give
an error if the local results differ from the buildd.
MfG
Goswin
Reply to: