Source package without a binary

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.

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

On 05/01/2012 18:26, Joachim Breitner wrote:
> 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?

You could build a binary package that just contains one file (the
test suite log, maybe?). This way, anyone could check that the test
suite was passed by the version of ghc being compiled by installing
the binary package.

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.

On Do, Jan 05, 2012 at 18:26:13 (CET), Joachim Breitner wrote:
> 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.

Why not installing the test-suite itself in the binary package, so that
users that install the package can run the test-suite on their own?