The latest dpkg version in sid now supports a standard script for vendor queries which is really quite extensible. A standard set of flags are allowed but custom flags can also be set. I propose that the emdebian-tools package supplies a conffile, /etc/dpkg/origins/emdebian-crush which contains the basic meta-data that describes Crush: Vendor: Emdebian Crush Vendor-URL: http://www.emdebian.org/crush/ Bugs: debbugs://bugs.debian.org Bugs-Package: buildd.emdebian.org Cross-Compiling: yes Grip-Build-Option: usecrush Blacklist: adduser coreutils perl python ldap Parent: Debian (not sure if Blacklist will be a comma-separated list or a space separated list at this time.) (Bugs-Package: could be used by reportbug.) (Note that just specifying 'perl' is not likely to be enough, unlike python which can usually be disabled by not looking for python setup strings. Therefore, the Blacklist could be quite large. This could be a problem as dpkg-vendor doesn't handle multiple line fields as cleanly as the real dpkg.) Vendor, Vendor-URL, Bugs and Parent are all typical dpkg-vendor values. What emdebian-tools (specifically emdebuild) will then do, is use the Grip-Build-Option value internally when post-processing the cross-built packages. Crush requires that the 'usecrush' DEB_BUILD_OPTION is passed to emgrip (to remove the docs and handle TDebs etc.) Blacklist is the interesting one - I'm considering using it in debian/rules such that a package can check for particular Essential or 'Priority: Standard' packages using findstring in the value returned from: $ dpkg-vendor --query Blacklist dpkg-vendor returns 1 if used with Debian, 0 (and the string on STDOUT) if used with a vendor that has this field. (So the actual call to read the string may need || true). To make this work, I need some extra fields in debian/xcontrol: Package: libgconf-noldap-2-4 Whitelist: ldap Optional: yes ... Package: libgconf-2-4 Blacklist: ldap Optional: yes ... Whitelist: marks the specified blacklisted package name as being omitted/dropped/disabled by this Optional package. Blacklist: marks the specified blacklisted package name as being required by this Optional package. Blacklist is not intended for changing the entire desktop environment, it's about changing the low-level system to remove awkward dependencies. Unless the vendor includes that blacklisted package in the Blacklist: field of the deb_vendor support data, the Whitelist package is ignored. The rules file for gconf would then check for the blacklisted package and put the necessary switches into place. For GConf, the noldap flag would only add --disable-ldap --disable-ldaps to the configure call (as the current patch set does). This flag is more flexible than relying on the simple name of the vendor. i.e. packages 'know' which components can be disabled in that package, so all they need to check is whether the vendor requires the supported changes to be activated. By specifying the package to be blacklisted, co-ordinated changes become possible whilst retaining the flexibility of different vendors being supported by the same xcontrol file. This allows both the original and the replacement packages to be Optional: yes. This also allows Cross-Compiling: yes to be used accurately instead of overloading it with other meanings. Alternative demonstration: Package: busybox-crush Whitelist: coreutils Optional: yes ... Package: busybox Blacklist: coreutils Optional: yes ... Then, something in debian/rules based on: DEB_VENDOR_BLACKLIST := $(shell dpkg-vendor --query Blacklist || true) ifeq (,$(findstring coreutils,$(DEB_VENDOR_BLACKLIST))) 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 (Yes, this disables busybox-udeb and busybox-static as well as the normal Debian build for initramfs usage.) xcontrol would need to handle this switch - replacing the Blacklist optional package with the Whitelist optional one in debian/control. Being a conffile, you can modify the values and dpkg will allow you to retain that build configuration. Such systems should *not* be used to upload to the www.emdebian.org/crush repository. (emrecent will probably gain support to read the contents of the relevant file in /usr/share/emdebian-tools/vendor/ and compare with the contents of /etc/dpkg/origins/emdebian-crush.) Comments? -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp6Hdnp1CrIk.pgp
Description: PGP signature