On Sun, 3 Dec 2006 00:23:21 +0300 "Wartan Hachaturow" <wartan.hachaturow@gmail.com> wrote: > Recently, while thinking about build-depends problems we are all > familar with, I came up with the following idea: what if all of the > packages we intend to cross-compile would have a special control-like > file in debian/, which would have build-depends in a way we need them, > that is, Host-Build-Depends for those packages that should be present > on host as is (such as flex, bison, whatever), and > Target-Build-Depends for those packages that should be present on host > dpkg-crossed. OK, I'm playing with this and trying to fit it into a build script for emdebian. So far, I've built libxml2, zlib1g, libglib2.0-0 and dash, plus a few others. I've got problems with sqlite which I know are fixable I just need to convert the openembedded build configuration to emdebian. (Some of these cross-built packages are in my own repository, cross-built for arm. However, these are demo packages and they may or may not work. They are also prone to being replaced / dropped without notice and without necessarily changing the version number. They are intended principally to make the .diff.gz accessible.) I can see how dpkg-checkbuilddeps can be integrated so that instead of just outputting the packages in a list, it could call 'sudo apt-cross -v -i $pkg' to meet the dependency. What I'd like now is some idea of how to generate the crossbuilddeps file. Given this Build-Depends line: Build-Depends: debhelper (>= 5.0.37.2), zlib1g-dev | libz-dev, autotools-dev, libreadline5-dev | libreadline-dev, binutils (>= 2.14.90.0.7) What would crossbuilddeps need to contain? If dpkg-cross outputs: "dpkg-cross: package debhelper doesn't provide any useful files. Skipping. " does this automatically and always mean that this package should not appear in the foo-Build-Depends in crossbuilddeps? Presumably it needs to be in Host- but not in Target? I've got: Host-Build-Depends: debhelper (>= 5.0.37.2), zlib1g-dev | libz-dev, autotools-dev, libreadline5-dev | libreadline-dev, binutils (>= 2.14.90.0.7) Target-Build-Depends: zlib1g-dev | libz-dev, libreadline5-dev | libreadline-dev What is needed is some way of determining that these entries are not just present on the build system but actually *correct* for the final package. I've fixed a bug in the dependency checking of apt-cross which I'll upload as 0.0.5 just as soon as apt-cross leaves the NEW queue in Debian. apt-cross v0.0.5 will then be able to install libreadline5-dev by checking for and downloading libreadline5 and readline-common, passing those to dpkg-cross (with -A for now) to build and install as a single set. I've tested this mechanism and it'll work. This will then be incorporated into the prototype emdebuild script in emdebian svn but to do this, I need some way of parsing the Build-Depends of the upstream package and generating debian/crossbuilddeps. The advantage we have over Debian and Build-Depends is that we know that Build-Depends is complete because we are taking packages that have been through the buildd system. There will be differences but we should be able to correlate those. How do we make that count? > If we are not cross-compiling, original dpkg-checkbuilddeps might be called. > If we are cross-compiling and the special control-like file is not > found, dpkg-checkbuilddeps might just return with successful return > code -- this situation would mean that there are no special > build-depends (unlikely, yes). Is there any way dpkg-checkbuilddeps can put a warning here that all may not be as it seems? Currently, it exits silently even if debian/checkbuilddeps is empty - it should probably check that certain fields exist and at least output a message asking "Are you sure crossbuilddeps should be empty?" or something. Also, I think it would be good to rename this package and make it part of emdebian-tools. Maybe call is emcheckdeps ? Do you have emdebian SVN access? I think we need this script in emdebian SVN in the tools folder so that I can incorporate it into the emdebian-tools package and the emdebian build scripts. I envisage it being called by the new emdebuild script - after whatever code I can arrange to parse Build-Depends into crossbuilddeps. > Disadvantages: this is not a real control file. Thus, for example, > those fields will not be present in .dsc, and, as a consequence, all > of the package building tools except those that call > dpkg-checkbuilddeps would not notice those fields (sbuild, apt-get > build-dep, etc.). The simplest method of sorting that is for emdebuild to patch debian/control with the required line from debian/crossbuilddeps, then the effect of crossbuilddeps will show up in the .dsc for the emdebian package. emdebuild can be adapted to do that job, just after it runs emcheckdeps. This would all take place before dpkg-* is run and before debian/rules is executed. Take a look at the updated emdebian/tools/em_make/* to see how your script could fit in here. (I'll probably rename the em_make folder in due course). My next task is to arrange an Emdebian perl library that will stop these scripts needing duplicate subroutines. The library will become a dependency of the emdebian-tools package. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpt49Efs9LrG.pgp
Description: PGP signature