I've added a simple script to emdebian-qa that can take some of the work out of maintaining debian/xcontrol files when maintainers make changes to debian/control. The script outputs errors to STDERR and a modified version of the file on STDOUT, it leaves fields like "Optional" in place and it maintains additional packages already listed in debian/xcontrol (which must already exist). The remaining issues relate to Build-Depends and Build-Depends-Tools as it is almost impossible for emxcontrol to update these reliably. For this reason, the script will stay in /usr/share/emdebian-tools/ and be used as an aid but not a complete solution. (Build-Depends are not automated in Debian either.) If Cross-Compiling: is not already set for the Source: package, it is added with a value of 'yes'. (If that is toggled to 'no' later, that setting is retained.) The order of the stanzas within the xcontrol file is determined by the order of the stanzas in the existing xcontrol file. In most cases, that should be the same as the debian/control file as the first step of creating the first xcontrol file is simply to copy debian/control and then edit the Build-Depends. The order of fields within each stanza is *reset* to the list gleaned from Debian Policy. This isn't ideal but it is a result of how the control and xcontrol files need to be parsed. (debian-xcontrol also shows this kind of behaviour). The intention with emxcontrol, therefore, is that the binary packages listed in debian/control will still exist - unchanged - in debian/xcontrol but with whatever Optional: and Cross-Compiling: fields are necessary for those binaries. Changes to the package will have to be implemented as amended Build-Depends and/or additional binary packages in debian/xcontrol and this package data maintained separately. Once Simon's debian-xcontrol package correctly supports all possible fields in debian/control and is able to drop packages from the generated control file, emxcontrol can then be used to automatically keep the emdebian-xcontrol.patch file up to date and debian-xcontrol (via xcontrol --build) can be used, prior to running dpkg-buildpackage, to action the changes described in the debian/xcontrol file. At this point, emdebian-tools will drop support for patching debian/control itself. (Indeed, at some point around this time, it may become necessary to drop support for patching anything except debian/rules.) The remaining question is where to put the xcontrol file itself - in the Debian packaging or only in our patches? For packages like gpe-* where there is no further customisation possible for most packages, or for other packages where the maintainer already has the necessary awareness of how to manage the xcontrol file, it can live in the Debian packaging. For the rest, we will continue to require emdebian patches to create the xcontrol file, then use emxcontrol to update it and xcontrol --build to action it. What I propose is: 1. I now start the NMU phase of the Emdebian Code Audit to get all existing cross-building support bugs closed either by the maintainer(s) or by myself as an NMU - subject to transitions being managed by debian-release. 2. Once those are done, I'll file a slew of new bugs to get us to the point where the only changes we still need are our own changes for functional purposes - i.e. xcontrol. 3. Ensure that *all* methods of implementing functional changes in packages can be handled by a combination of debian/xcontrol and patches for debian/rules. This will require updates for debian-xcontrol and parts of emdebian-tools. I do not envisage this stage being complete before DebConf. 4. Migrate emdebian-tools to multiarch support - if multiarch is not implemented in Debian before Squeeze, Emdebian Crush 2.0 might not make it to a release and we'd only have Emdebian Grip 2.0 based on Squeeze with a view to restarting Crush at 3.0. Maintaining patches for debian/rules is a problem in and of itself. Some maintainers may be willing to accept patches that support customised packages that are never built in Debian and we need to explore those options at events like DebConf. One option is that xcontrol files themselves become configurable via a combination of machine:variant and dpkg-vendor support. emsource could be taught to get the xcontrol file (or a patch to create it) from a particular location, overriding whatever is in the default emdebian-xcontrol.patch in SVN (and then ignoring any changes so that the default patch is not altered by the override). The first result of these steps is that packages that depend on things like adduser will also need a new binary package using the same principles as libgconf-noldap-2-4 etc. Every functional change we make must result in a new binary package being described in debian/xcontrol and will usually result in that binary replacing the standard Debian binary package. There is, currently, no convention on how these packages should be named. It's fairly simple to expect that single changes (like removing LDAP symbols) can be expressed via a no$foo addition to the binary package name (we are nearly always removing functionality/symbols, not adding it). More extensive changes (like a whole new config file for busybox - the one package that will gain functionality in most setups) need to be specific to particular vendors, so Emdebian Crush would create busybox-crush. Any system based on Crush that needed a tweaked busybox config would then need to provide a replacement xcontrol file that provided for the modified package - *without* removing standard busybox, busybox-static and busybox-udeb from the xcontrol file (although these can be removed from the generated debian/control file before the build starts). Such builds would also need to provide the relevant config file and possibly patches for debian/rules. The machine:variant support can cope with this by creating package-specific patches in $workdir/machine/$machine/$variant/$initial/$package/ - e.g. /opt/emdebian/machine/atom/default/b/busybox/emdebian-rules.patch /opt/emdebian/machine/atom/default/b/busybox/emdebian-config.patch /opt/emdebian/machine/atom/default/b/busybox/emdebian-xcontrol.patch $ emsource -a i386 -v -m atom -c busybox etc. (Although this support already exists in 2.0.0, the rest of the Crush build system is not yet in a satisfactory state to implement any of these in real builds, it's just an example.) It is entirely possible that dpkg-vendor support can be co-opted into also implementing machine:variant support if there is only one machine for that vendor, to save duplication. Equally, one machine:variant could have multiple vendors. Additional functionality that still needs to be implemented is to summarise the actions implemented by the use of the xcontrol file in the debian/changelog so that it is obvious what has been done when the package comes to be uploaded. Once this support is ready, the emdebian website will need to gain some support code to move the .changes files to a long-term location and parse them as part of the description of the package and the changes we have made. (This is possible because we do all the work before calling dpkg-buildpackage and already add a new version to the changelog anyway.) I'm thinking that some of the code from emxcontrol can be migrated into Emdebian::Tools and used by em_make (which usually makes the changes to the debian/changelog) for this purpose. I'm hoping that this changelog support can also be in 2.0.1. Finally, now that emdebian-tools has been split into four separate source packages, I will not be making quite as many releases of each one and I will start uploading incremental releases to Debian. I may still use the Emdebian toolchain repository for emdebian-* packages once in a while but the pace of development should be compatible with uploading to Debian each time. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpfriPWPOtFv.pgp
Description: PGP signature