[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DEB_VENDOR and xcontrol support in Emdebian



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: pgpyXZ8kzjc53.pgp
Description: PGP signature


Reply to: