[ Installing toolchains ] [ Cross building ] [ Root filesystem ]

Emdebian Howto (continued)

Mixing Emdebian and Debian

The future of the Emdebian root filesystem is to support a complete Emdebian distribution of cross-built packages. Yet Emdebian also aims to support mixing Emdebian and Debian packages from the standard 'arm' port. A number of issues (and solutions) are involved in such mixes:

• Dependencies will differ. Emdebian packages are likely to be built with optional upstream components disabled. Other components may be split into new packages so that users have a choice of installing 'libfoo-xml' as well as 'libfoo-sqlite' etc. where such upstream support exists. Debian generally enables every upstream option that can be made to work and only splits packages where there is a benefit to be achieved within the repositories. Emdebian needs to separate each upstream option into dedicated packages as well as making further package splits without explicit upstream support. These problems will tend to show up as Debian packages simply 'not working' because the Debian package assumes that the 'foo' package contains 'bar' when Emdebian has 'bar' in the 'foobar' package instead. Although virtual packages and meta packages could be used here, the best solution is to try to provide a cross-build of the relevant package(s) that are modified to use the Emdebian dependency tree. Dependencies remain the single most likely reason to need to cross-build a Debian package for Emdebian.

  Example : busybox vs coreutils

  Emdebian makes changes to the packages classed as "Essential" in Debian - including allowing busybox to be used in place of the usual Debian base packages, like coreutils. dpkg automatically prefers a package tagged "Essential" in debian/control, even if another package provides the same package name so when busybox provides coreutils, other packages install successfully but apt complains and offers to remove busybox and install coreutils. To allow busybox to remain, the Emdebian build of coreutils is no longer classed as "Essential" - in many ways, the concept of "Essential" no longer exists in Emdebian - but a mixed Debian/Emdebian system could offer to remove busybox and install coreutils (amongst other dependencies) because the Debian package will remain "Essential" at least for the time being. Similarly, dpkg itself is no longer marked as "Essential" in Emdebian.

• dpkg filtering. Debian packages must include certain files that Emdebian does not require - debian/copyright, ChangeLog and other files as well as man pages, info pages and other documentation. Filters created by the Emdebian installation process can remove these files from the installation but the downloaded .deb package remains the same size as in Debian. Where download bandwidth is limited, the smaller Emdebian cross-built packages will be more useful. In time, it is hoped that Emdebian can use filtering when building the cross-built .deb package in the same manner as filtering upon installation as this will make it a lot easier to prepare Emdebian patches that can be applied within Debian.

• Transitions. Until such time as Emdebian has a fast method of autobuilding cross-built packages, it is strongly recommended that users who mix Emdebian packages with Debian packages track Debian testing and not unstable. The frequent transitions in Debian unstable will only aggravate the dependency problems inherent in a mixed system. This becomes even more important immediately after a Debian release when it is common for a lot of transitions that were held back for the release are uploaded to unstable at more or less the same time. When such transitions involve toolchain packages like gcc or glibc the Emdebian cross-built packages can be delayed significantly.

• Translations. Emdebian handles translations in a similar manner to OpenEmbedded - one package generated per translation. Whilst this is acceptable with the small number of packages currently maintained, it is already proving difficult to maintain and is not scalable. A wider discussion is needed within Debian about how to manage translations from a variety of perspectives; seeking to make it easier to update translations without requiring package rebuilds, separating translations into "sub-repositories" to avoid bloating the archive and how to manage the resulting package mix. Emdebian will adapt to the Debian method in due course. In the meantime, the current behaviour can sometimes complicate autobuilds of Emdebian packages and cause delays. The principle problem is identifying the translations within the source package. po/ is not always present, some packages contain more than one set of translations, some packages include translation files in tarballs within the source. The current method of downloading the actual Debian binaries and checking them for translation files is reliable but slow.

[ Installing toolchains ] [ Cross building ] [ Root filesystem ]