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. Does it have to be a separate file? The installer team have a custom line in debian/control, maybe we can ask for the same? Or just patch the existing line? How different are the contents of the two lines, to each other and the original Build-Depends? How many of those changes are likely to be relevant upstream? The alternative is to patch Build-Depends during the (to be written) emdebian build scripts. > Advantages of this approach are more or less obvious: we remove any > wild guesses from package building tools, and rely the task of > providing correct build-depends on feeble maintainer's shoulders :) That would be the same when using a patch. > 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.). A patch would be included in the .diff.gz - that should be sufficient because that will be applied before debian/rules is run. Maybe the emdebian scripts could include a handler that replicates what apt-get build-dep does, taking into account the changes. (I've yet to decide if *all* debian/patches are to be applied or just the NN-emdebian-foo.patch files but, currently, emdebian-specific patch files should be named to indicate this.) > Tools that we might need in future (such as sbuild) may be patched to > check this file if they run on an unpacked source (actually, sbuild > already does that, checking debian/.sbuild-build-deps or something > like that), but they would still fail if they run on a packed one with > .dsc. It would be easier to handle a patch to an existing file. > While this can easily be fixed patching dpkg-dev, I am not sure what > else will break finding unusual fields in .dsc, and this will also > introduce YADI (Yet Another Debian Incompatibility) which I'm not that > happy about. The patch would only exist in the emdebian repository so that's not a problem. > Attached is a sample implementation of this idea -- I can have a look at that later, I hope. I've built libglib2.0-0 cross-built for arm as an emdebian package but I now need to clean up the process and automate as much as I can. This will be the basis of the emdebian em_make script that makes an emdebian package from a Debian one. Part of that is (finally) sorting out some code to implement Julian's summary of how the release side of emdebian SVN will work. Then we will have our first emdebian package in the target repository. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpGIlDIdzqTM.pgp
Description: PGP signature