Emdebian Bootstrapping ====================== Cross-building can get very confusing at times. The confusion only increases when dealing with a chroot. This document tries to cover some of the reasons, some of the problems and tries to provide some clarity, at least as far as how chroots can be used in Emdebian. There are multiple ways that Emdebian can relate to bootstrapping and chroots. The most common method of using a chroot within Debian is pbuilder and the pdebuild wrapper and this is the primary inspiration for using chroots in Emdebian. Other methods revolve around QEMU or scratchbox and whilst this code may be able to support such uses later, there are key differences in how and why this method is separate. EMDEBIAN PBUILDER CHROOT MODEL ============================== The Debian pbuilder package exists to ensure package dependencies are complete and to provide an environment to automate package building on all supported Debian architectures without cluttering the build machine with every library and dev package in the entire archive. This is particularly useful when building GUI packages that can have two dozen dependencies or more. In Emdebian, this separation between the build system packages and the chroot packages becomes even more useful because cross-building often involves not only installing the library and -dev package for the build architecture (e.g. i386/amd64) but also building and installing the same library and -dev package (with dependencies) in the TARGET architecture, e.g. arm, with apt-cross and dpkg-cross. The chaos that could result from trying to upgrade the packages on an Emdebian buildd system with a duplicate set of cross dependencies is truly scary. In the pbuilder model, an Emdebian chroot is the SAME architecture as the buildd - i386 on i386 etc. This mimics how emdebian-tools normally work. Packages are then downloaded, patched and cross-built for the target architecture, just as outside the chroot. This model, the pbuilder model of an emdebian chroot, concentrates on dependencies rather than the actual cross-building process. Inside such a chroot, cache files are used as normal to avoid having to run the cross-compiled code during the build. The Emdebian chroot is similar in size to a normal Debian pbuilder chroot, mainly because it is a full build environment, not an installation environment. This directory contains my experiments with debootstrap, using this pbuilder model, trying to make a complete Emdebian cross-building environment that can be compressed to a base.tgz. Changes to the chroot can be discarded, just as with pbuilder, allowing dependencies to be tested. The main benefit is that packages can be built without having to install long chains of cross dependencies via apt-cross or dpkg-cross on the main system. To me, it's the only way to cross-build GUI suites like GPE against a background of changing dependencies. In the pbuilder model, Emdebian builds a chroot for the build architecture (amd64/i386 etc.) - except that it will run emdebian-tools instead of pbuilder to create the arm binaries (or whichever architecture is the dpkg-cross default). I expect the same code to work for arm chroots on amd64 etc, but mechanisms already exist for those so it's not the priority. In order to make best use of the existing pbuilder code, these are shell scripts whereas the rest of emdebian-tools uses perl. DEPENDENCIES ------------ To emdebianise and cross-build packages, the chroot needs to install emdebian-tools. This brings in the majority of dependencies to support building Debian and Emdebian packages. This (current sample) code uses part of the pbuilder source so that the eventual chroots behave as similarly as possible to pbuilder and pdebuild in Debian. Therefore, the emdebian pbuilder chroot is NOT designed or intended to be installed on any embedded device - it is intended for cross-building packages for Emdebian only. See the SLIND installer for more information or the emsandbox script in emdebian-tools. empdebuild depends on pbuilder and installing emdebian-tools within a chroot causes pbuilder to be installed inside the chroot. Whilst empdebuild and emsandbox could be split out into a separate package to prevent pbuilder being needed inside the chroot, there are corner cases where this can be useful providing sufficient care is taken. DIFFERENCES TO PBUILDER ----------------------- 1. emdebian-tools handles the 'installaptlines' subroutine. 2. emdebian-tools dependencies handle the installation of build-essential dpkg-dev and apt that pbuilder normally does separately. 3. emdebian-tools handles the BUILDPLACE via debconf. 4. Other embootstrap options are hardcoded - BUILDRESULT is placed in BUILDPLACE, APTCACHE also and APTCACHEHARDLINK is set to yes. 5. emdebian-tools provides the emdebianised source package and patches. EMDEBIAN NATIVE CHROOT MODEL ============================ The same code should also be able to create a native chroot so that the cross-built packages can be installed alongside each other for more testing. These chroots have already been tested and instructions exist in the Wiki: http://wiki.debian.org/EmDebian/CrossDebootstrap Trying to cross-build inside scratchbox limits you to where scratchbox will install which is only certain architectures. emdebian-tools is about cross-building Debian packages using normal Debian tools on a normal Debian system. Emdebian and emdebian-tools are designed to make building inside scratchbox redundant because it simply isn't sufficiently flexible. A scratchbox2 has been mooted but nothing has happened yet. Cross-build using normal tools (maybe using the chroot as above) and then test either on a native device or via scratchbox if you really have to. An Emdebian native chroot would be an arm chroot running on an amd64 system - indeed it would need to support creation of a chroot *for* any supported Debian architecture and be able to create and run that chroot *on* any supported Debian architecture. This is only the first draft - if there are areas that need further clarification or updating, please email the debian-embedded mailing list.