Packaging a library that requires cross-compiled code
[I've only just subscribed, please forgive me if I got something horribly wrong]
I was redirected here for advice from #debian-mentors, following a
packaging question I have. The short summary: I'd like to package a
library which requires a tiny blob of cross-compiled code to run, and
don't know how to achieve this in a debian-friendly way.
Context: the code I'd like to package is a Python package and
associated Python scripts, that enable low-level communication with a
Lego Mindstorms NXT brick over USB. This is the newer Lego Mindstorms
brick, which to the best of my knowledge currently has no supporting
libraries available in Debian (support is available for the older, but
completely different RCX model).
My module enables low-level communication at two levels: a wrapper
around python-pyusb to facilitate scanning for a brick and accessing
it, and an implementation of the simple command protocol used by the
onboard bootloader. This is a library aimed squarely at developers who
want to replace Lego's firmware with something else (in my case, an
open source high kernel I'm working on).
One of the tools provided is called `fwflash`, which takes a binary
firmware image and writes it to the brick's flash chip via the
bootloader. One of the steps in the flashing procedure is to upload a
tiny (136 bytes) driver for the flash controller into the brick's ram,
to oversee the actual flashing process. The brick cannot be flashed
without the help of this driver. (for those who care, the flash memory
is single-plane, which cannot be simultaneously read and written,
which requires the use of an in-ram driver for the few instructions
that actually perform the write. Attempting to drive the entire
process through the bootloader crashes the brick.) And, of course, as
the brick is based on an arm7 architecture, this flash driver needs to
be cross-compiled. From an architectural POV, the flash driver is an
internal implementation detail, the end user of the library doesn't
care about the technicalities that forced it into existence.
Problem: the flashing tool is unusable without this tiny piece of
firmware, but that code can only be compiled with a properly built
arm7tdmi cross-compiling gcc, which is not available in Debian. I
built my own from gnuarm.com.
Therefore, question: how should I get from this situation to having a
working .deb (including the cross-compiled driver), while at the same
time playing nicely with Debian packaging policies?
Possible solutions that we came up with on #debian-mentors:
1) Ship a built copy of the code in the package's .diff.gz, and DTRT
at package creation time to move the .bin from debian/ to the right
place in the staging tree. The source code for the .bin is in
.orig.tar.gz, under a free license. Anyone is free to modify or
rebuild the .bin, provided they obtain an arm7 cross-compiler by
non-debian means (instructions provided). People who just want to
rebuild the package can do so, without caring that there is
cross-compiled code involved.
Pro: dead simple, the packaging problem goes away. Con: means shipping
a binary blob in the source distribution, which appears to be frowned
upon, regardless of whether the source is also freely available in the
2) Package an arm7 cross-compiling gcc with just the right set of
options, integrate that with the packaging tools, and then package
with a Build-Depends on the cross-compiler.
Pro: feels like the Right Way, in a perfect world. Cons: opens the
floodgates of packaging cross-compilers, likely requires
additions/modifications to packaging tools, and takes way more time
than I'm personally ready to put into packaging my code.
3) Somehow make the packaging tools properly cross-compile the .bin
without having a cross-compiler package around. This was briefly
suggested on #debian-mentors, but I have no idea how this would be
Pros: less time involved than 2), would make the package
self-contained. Cons: building a cross-compiler in the packaging
process just to build a 136 byte binary blob feels like killing a flea
with a bazooka, and makes building the package much, much longer than
it should be, given the amount of code and logic it actually carries.
4) Give up and stay away from the Debian main repositories, just put
the package up on a private package repository.
Pro: trivial solution. Cons: I'd like to do things right rather than
cobbling something together.
There you have it. Ideas, thoughts?