I've just built an updated build of busybox for Emdebian Crush using emdebian-tools 2.0.2 which is in final testing, hopefully for release tomorrow. Although the level of changes could make this release worth calling 2.1.0. (if it works). Apart from the usual range of changes (which I'll post prior to the release), there is a fairly large change in the flexibility of emdebuild. Perhaps the easiest way to see the effect is to see part of the build results: Changes: busybox (1:1.13.3-1em1) unstable; urgency=low . * New release for Emdebian Crush. Cross-build. * xcontrol: omitting binary package busybox-udeb. * xcontrol: omitting binary package busybox-static. * xcontrol: omitting binary package busybox. Checksums-Sha1: 489dd83912ecc15fff6db6de17ba4ce145654e16 829 busybox_1.13.3-1em1.dsc fc6b5cfd73572b5f98731cee5211a0ddc0adbf40 28279 busybox_1.13.3-1em1.diff.gz b506a89a84437da05157b877a0890329a33f0c26 471594 busybox-crush_1.13.3-1em1_armel.deb The normal Debian build results in busybox, busybox-static and busybox-udeb packages. :-) How is this done? 1. emdebuild will support -V|--vendor as well as the DEB_VENDOR environment variable. 2. emdebian-tools includes vendor support for Emdebian Crush as a file in /etc/dpkg/origins/ - emdebuild, like all scripts in the emdebian-tools binary package defaults to emdebian-crush. 3. emdebian-grip includes vendor support for Emdebian Grip as a different file in /etc/dpkg/origins/ - all scripts in the emdebian-grip binary package default to emdebian-grip. 4. emdebian-tools still depends on emdebian-grip because it uses the emgrip DEB_VENDOR support (yes, that's been added too) to post-process the cross-built binaries (at this stage these could be quite unchanged from a native build for the same architecture). 5. Now add in the xcontrol - when an xcontrol file includes Optional packages, em_make details which packages are added and which are omitted under the instructions of the xcontrol file, as notes in the debian/changelog (which is then put into the emdebian-changelog.patch file). Note that xcontrol is not specifically sensitive to DEB_VENDOR. That is a bridge we haven't crossed yet and may need to be package-specific. It's more like just allowing vendor and xcontrol to be used together, to describe their actions within the changelog (at least for the em1 build) and cooperate within their roles. How does busybox implement this? Emdebian patch files include a complete config file that is entirely separate from any of the existing Debian config files. Alongside this, a debian/busybox-crush.install file is patched into place. The Emdebian patch files add a conditional setup to debian/rules: DEB_VENDOR=$(shell dpkg-vendor --query vendor) ifeq (,$(findstring emdebian,$(DEB_VENDOR))) build: $(STAMPS_DIR)/build_deb $(STAMPS_DIR)/build_static $(STAMPS_DIR)/build_udeb binary-arch: binary-arch_deb binary-arch_static binary-arch_udeb else build: prepare-crush $(STAMPS_DIR)/build_crush binary-arch: binary-arch_crush binary-indep busybox-crush: build endif prepare-crush: cp debian/emdebian debian/config/crush # this should not be done here xcontrol build > debian/control || true binary-arch_crush: DIR = $(BUILD_DIR)/build_crush binary-arch_crush: export DH_OPTIONS = -pbusybox-crush binary-arch_crush: $(STAMPS_DIR)/build_crush dh_testdir dh_testroot dh_clean -k -d dh_install --sourcedir=$(DIR) $(MAKE) $(CROSS) -f debian/rules binary-arch_all As noted, there is room for improvement here - emdebuild will probably run xcontrol itself rather than corrupting the build. It is possible (but not currently implemented) for these patches to the debian/rules file of busybox to support multiple vendors by use of variables. Quite how the actual config modifications are stored and modified is unclear - but that is specific to busybox, most packages won't need it. Note that 'xcontrol build' doesn't work with 99% of Debian packages because we need some more fixes (Simon?) to allow fields like Uploaders and VCS* etc. The really nice thing with this change in busybox is that by only building the one config needed by Crush, the build takes half the time. (Crush won't be using busybox-udeb any time soon and the config used for that package is almost certainly useless to any Emdebian Crush device anyway.) Other issues remain - the .changes file lists the omitted binaries, probably because xcontrol doesn't yet omit dropped packages from the debian/control file it builds. Another new script is 'emxcontrol' - a method to generate the xcontrol file for the first time. It starts with debian/control, adds a single Cross-Compiling: yes field for the Source package. 'emxcontrol' is primarily to be used for the reverse process of xcontrol from Simon. emxcontrol keeps the xcontrol file in sync with the debian/control file. The principle needs to be: "Make no changes to binary packages that exist in Debian - add a new package instead." emxcontrol will then keep all the binary packages in Debian up to date with the changes made within Debian and add your customised packages, along with preserving any Optional: settings you've made in debian/xcontrol as well as preserving the *manual* changes needed to determine the dividing line between Build-Depends and Build-Depends-Tools. So there's more to do. However, the combined effect *should* be that nearly all the 'xcontrol' tags in the Emdebian Code Audit can be removed because the tools will be able to take over the generation and update of simple xcontrol files and the general upkeep (albeit with needed manual changes being pointed out) of xcontrol files that have only minimal requirements (like Build-Depends-Tools maintenance). One interesting overlap will be DEB_VENDOR support for Blacklist and Whitelist settings in how xcontrol is used. It is possible for the vendor support to declare that ldap is blacklisted. What is needed for xcontrol to work conditionally. To declare that a binary package is Optional *only* if a particular string occurs in this "blacklist" variable. i.e. if ldap occurs in the Blacklist, the libfoo-noldap package will not be activated. If it does, then libfoo is disabled and libfoo-ldap replaces it. $ dpkg-vendor --vendor emdebian-crush --query Blacklist coreutils perl python ldap adduser The xcontrol file, therefore, needs to have a field in the binary package that declares that this binary package (whether that package exists in Debian or is additional), which allows xcontrol to match the blacklist with the package support and do TheRightThing. Package: libgonf2-4 Optional: yes Blacklist: ldap ... Package: libgconf-noldap2-4 Optional: yes Whitelist: ldap ... Package: libgconf-dev Optional: no ? Simon? -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpM_UDZRlIvi.pgp
Description: PGP signature