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
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? :-)
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org