On Wed, 6 May 2009 14:21:58 +0100 Neil Williams <codehelp@debian.org> wrote: > > - "Optional": This package is not built by the regular build target. > > There needs to be a policy how to build these packages, my suggestion > > would be "build-<packagename>" and "binary-<packagename>" targets. I'm trying this out with busybox because Debian finally has updated to 1.13. The idea is to provide a debian/config/crush config file (currently using an almost standard 'make menuconfig' one) in the Emdebian patches alongside a working debian/xcontrol file and patches for debian/rules to support the xcontrol features. If you use: $ emsource -c busybox ensure you have debian-xcontrol (from Sid) installed before building with emdebuild or dpkg-buildpackage -a I plan to parse debian/xcontrol and construct a changelog entry that can be put into the .changes file, summarising what was dropped, what was added etc. : Changes: busybox (1:1.13.3-1em1) unstable; urgency=low . * New emdebian release. * xcontrol: add busybox-crush binary package. * xcontrol: omit busybox binary package. * xcontrol: omit busybox-static binary package. * xcontrol: omit busybox-udeb binary package. At some point, these .changes files need to be retained on www.emdebian.org and become part of the information about the package in the repository - probably as a link from the current package search pages. > > This allows e.g. toolchain packages to list the cross variants in the > > xcontrol file so an xcontrol aware autobuilder can see them and > > specifically request them to be built. This is per-binary, defaults > > to "no". "specifically requesting packages to be built" presumably means relying on 'fakeroot debian/rules $target' which in turn means not calling dpkg-buildpackage at all. Yes, 'dpkg-architecture -a$arch -c' can do the job but with discussions around environment variables and lack of "official" support for calling debian/rules directly, this could be problematic. Calling debian/rules may well end up as only useful for debugging and is explicitly unsupported in the current emdebian-tools build structure because various cross-build setup stages are not available. (This is particularly important for those packages that still have problems with libtool.) It probably needs to be built via DEB_VENDOR support in dpkg-buildpackage which then triggers the relevant sub-builds within the debian/rules file using normal dpkg-buildpackage procedures. Unfortunately, this creates a disjointed build - changes in debian/xcontrol are not necessarily linked to the supporting changes in debian/rules as implemented by DEB_VENDOR. I think this is acceptable though - it retains debian/xcontrol as a meta-data file without turning it into a secondary instruction set. The actual decisions about what really gets built are retained solely within debian/rules and debian/xcontrol merely provides the data to make those choices. All xcontrol achieves in this situation is that the final .changes file doesn't list the unbuilt packages as all the real work has to be done in debian/rules anyway. However, this is still important because CDBS and debhelper 7 will always build every package listed in debian/control. There are two reasons for Crush to use Optional: 1. To change functionality in an existing source package by replacing a standard Debian binary package with a renamed Emdebian binary package. The standard Debian binary package (which would normally cross-build but is too bloated for Crush) is deemed "Optional: yes" and the replacement binary package is deemed "Optional: no && Cross-Compiling: yes". (Optional: no && Cross-Compiling: no makes no sense for Crush and the autobuilder would need to throw an error. I'll note that debian-xcontrol is likely to gain this support and the autobuilder will fail when xcontrol fails.) 2. To omit a language binding or other binary package from an existing source package that would otherwise fail to cross-build. Optional: yes && Cross-Compiling: no This leads to potential misunderstandings about "Optional". The replacement package is Optional: no. However, under the original description, the renamed package is not built by the normal Debian build so could be understood as Optional: yes. The omitted package is (logically) Optional: yes for different reasons - because it is part of the normal Debian build but can be optionally removed. However, as that is also flagged as Cross-Compiling: no, it is removed from the build. What we actually need is: Package: libgconf-noldap-2-4 Optional: no Cross-Compiling: yes Package: libgconf-2-4 Optional: yes Cross-Compiling: yes Package: python-xml Optional: yes Cross-Compiling: no Package: busybox-crush Provides: busybox Optional: no Cross-Compiling: yes Build-Depends-Tools: debian-xcontrol Package: busybox Optional: yes Cross-Compiling: yes The "optional" keyword has hence been overloaded too many times and has become unclear. I think Optional should be restricted to *only those packages that can be dropped* from the normal Debian build and that these packages are dropped from the output of 'xcontrol build'. If a package is Optional: yes and Cross-Compiling: yes, then Optional should override Cross-Compiling and the package be omitted. This allows debian/xcontrol to correctly indicate which packages do cross-build and which do not, independent of decisions to drop dependency chains or similar. (i.e. it is perfectly acceptable to have gconf with ldap support - IIRC it does build - but it doesn't make a lot of sense when the only point of cross-building in Emdebian Crush it is to make the dependency chain smaller.) This would allow "Optional: no && Cross-Compiling: yes" packages to be retained and de facto replace the dropped packages. It might be better to therefore rename "Optional" as "Omit" to preclude the possibility that an additional package (like libgconf-noldap-2-4) can be tagged "Optional" because it is an option that we are adding to the package when what we actually need is to deem the standard Debian package as suitable for omission and our own package to replace it. Where a replacement binary package is not a library, should it Provide: the replaced binary package? The above snippets then become: Package: libgconf-noldap-2-4 Omit: no Cross-Compiling: yes Package: libgconf-2-4 Omit: yes Cross-Compiling: yes Package: python-xml Omit: yes Cross-Compiling: no Package: busybox-crush Provides: busybox Omit: no Cross-Compiling: yes Package: busybox Omit: yes Cross-Compiling: yes This removes any overlap between Omit: and Cross-Compiling: and allows for distinct handling of each situation. busybox-crush is then built instead of the standard Debian busybox target, using our own busybox-crush config setup and our own busybox-crush.install file in the busybox sources. It is also up to us whether to retain busybox-static and busybox-udeb by toggling Omit: without giving the misleading impression that these are omitted because they don't cross-build when, of course, they do. Importantly, the actual instruction to build the busybox-crush target must still be 'fakeroot debian/rules binary-arch' so that dpkg-buildpackage can still operate. debian/rules can include a busybox-crush: target but it should point at binary-arch. The actual decision about which binary-arch instruction is used is then down to conditionals within debian/rules which can be influenced by DEB_VENDOR or other mechanisms within debian/rules itself. It doesn't matter how that support is delivered, as long as it is in place prior to calling dpkg-buildpackage - so we can continue to test the mechanisms via 'emsource' patches and then push those changes into the Debian package. > I'll build that support into emdebian-tools. It will be fairly simple > to pick up the field in debian/xcontrol and activate those targets. ... as long as 'xcontrol build' removes the unwanted packages from the output (redirected to debian/control) without errors about Uploaders etc.). A major potential problem is that debian-xcontrol is positioning itself as being used as part of the build process - but modifying debian/control after executing debian/rules is meant to be a Policy violation. Using debian-xcontrol in debian/rules would therefore be unwelcome to most people in Debian, so running 'xcontrol build' in emdebuild would mean that these packages would not build correctly with dpkg-buildpackage -a. Do we just accept that? (If we do, do we prohibit the use of: Build-Depends-Tools: debian-xcontrol ? What about: xcontrol build > debian/control || true in debian/rules?) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpuAJPPsDcJl.pgp
Description: PGP signature