For the last couple of years I have been working with the AT91RM9200 ARM9 chip from Atmel. This is a very nice, fast, cheap CPU when combined with some SDRAM and NOR flash. One of the bigger problems I faced getting started with it was managing the sheer amount of sources that go into a modern Linux implementation. Many embedded folk just generate a giant tarball which is their whole root filesystem, they don't track what versions are where and as a result providing sources for their magic tarballs can be a pain in the ass for them. I knew I didn't want to repeat this method from the start, so I began to work towards being able to use the RPM packaging system even with my crosscompiled stuff. Having the full RPM app and database doesn't make sense for an Embedded system though, for example our standard AT91RM9200 platform only has 8MB of flash for all nonvolatile storage. I found that the excellent busybox had the start of an rpm implementation already, but although the code was really well-written, the implementation was not complete enough to do anything useful: it did not keep a database and there was therefore no possibility to erase packages, for example. Over a few months I added more functionality to the busybox applet, including keeping a "database" of installed RPM headers down /var/lib to emulate most of the capabilities of real RPM. With this in place, I then went on to package all of the apps that I was interested to run on my distro. There are numerous advantages to formalizing the management of code into packages once you accept that you will only place packaged stuff on the device. Creating an RPM binary also creates a source RPM (SRPM) that is contains all of the sources and build specification for that binary, and both the binary and source are versioned. Therefore so long as you offer the matching SRPM at the same time as you give someone the binary RPM, your GPL requirements for giving sources are solved in one stroke. The patchlevel of any device can now be interrogated and used to select updates as well, in a formal manner. You can also express the need in a package to have "required" dependent packages of specific versions, reflecting a common situation where after some release you need a library of a certain version for it to work. The "cost" for this level of control over your device boil down to: no more ad-hoc building. Even development builds are done through rpm packages. We provide a script that will remotely install over scp and ssh the latest version of a given package from the host commandline, even one that rebuilds the package before installing it remotely, and for every single edit you can be certain the sources are captured in the SRPM. We found a typical system is using only 100K of uncompressed data (typ 50K on jffs2) to maintain the RPM headers that make the packaging work. That is not significant even on a box with only 8MBytes of Flash. Check out the Wiki at http://octotux.org for more details and the repository which contains the packages.