[I've only just subscribed, please forgive me if I got something horribly wrong]
Hello, 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 source distribution. 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 implemented. 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? - Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
