On Sun, 3 Dec 2006 12:23:35 +0300 "Wartan Hachaturow" <wartan.hachaturow@gmail.com> wrote: > On 12/3/06, Neil Williams <linux@codehelp.co.uk> wrote: > > > 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? > > I seriously doubt we can. We're not installer team, and our needs are > not nearly as important for Debian. Then a patch would seem appropriate - held in emdebian SVN and applied like the other emdebian patches - by the emdebian tools before any other commands are run. i.e. within the emdebuild wrapper that I'm working on. (Maybe you've missed some of the discussions / Wiki page changes since LinuxWorld Expo?) > > 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? > > upstream being what -- a Debian maintainer? None of them, because > Debian builds natively. That's fine. (and yes, upstream == Debian.) > > The alternative is to patch Build-Depends during the (to be written) > > emdebian build scripts. > > I don't really know what "emdebian build scripts" are going to be, but > dpkg-checkbuilddeps is ran before any single line of rules is > executed. And emdebuild will apply the emdebian patches before dpkg-* is run too. The build scripts consist of: em_make - one-time derivative of dh_make that emdebianises a debian source tree. (Includes creating an entry in debian/changelog with the emdebian version string.) emlocale - run by em_make and then run independently at each update to handle the translations. Early versions of those are in SVN - I'm working on them now and I hope to commit the latest versions today. The next stage is that debian/rules is patched to remove dh_installman etc., other patches are applied to create $arch.cache files that skip the AC_TRY_* macros in ./configure. The patch to ignore dh_installman etc. can be automated - probably made part of em_make - and I'm looking at how a script can at least assist in the generation of $arch.cache data by scanning configure.in|ac for troublesome macros and parsing the Debian build logs for the $arch to lookup the relevant cache setting. A bit of get(build.log), a bit of $configure =~ /AC_TRY/ in Perl and I should be able to create at least a helping hand if not a working $arch.cache file. em_make will then generate (and apply) a patch for debian/rules to call ./configure using --cache-file=$arch.cache at the head of the other ./configure options. This is all "being written" right now - literally, I've only just completed a build of libglib2.0-0 and I'm in the process of writing the scripts that will automate the steps I had to do manually to get it to cross-build using the emdebian composite method. The patches themselves (for debian/rules and $arch.cache) can be held in emdebian SVN and applied by the emdebian build scripts before any other package building code is run. The patches will also be included in the emdebian .diff.gz so SVN will really be for packages where more than one emdebian developer is involved in the emdebian packaging. This way, the patches are applied by dpkg-source -x when called with an emdebian version string. for foo 1.2.3-1 (Debian), we'd have foo 1.2.3-1em1 in emdebian, therefore: $ dpkg-source -x foo=1.2.3-1em1 will download the emdebian .diff.gz and apply that to the source (provided you have the emdebian target repository in /etc/apt/sources.list). The emdebian .diff.gz includes the underlying Debian .diffs and has the emdebian changes overlaid. > > 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. > > And how are you going to generate those diffs? Using the normal dpkg-* build process. We generate an emdebian diff.gz that includes all the changes and includes the debian .diff.gz. http://wiki.debian.org/EmdebianMetaData This is already working - I've cross-built packages using the composite method and the patch and diff process is working fine. It just needs to be automated cleanly. :-) > > (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.) > > Hm. If you are thinking about this kind of patches, then that won't > work -- they are applied in rules target most of the time. Precisely. That is why we apply the patches *before* rules is run by using a separate wrapper. > > > 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. > > Every Debian incompatibilty is really a problem, since you have to > maintain it yourself. If this is a patch to dpkg, you have to rebase > it with each dpkg release, etc. No, these are patches to debian/* files and a few upstream files if necessary. I'm hoping that changes in debian/* and the addition of an $arch.cache file will be sufficient for many packages - after all, these are packages that have built natively on the $arch for which we are cross-building and the emdebian build includes all Debian patches necessary to achieve the native build. The emdebian patches are not debian-incompatible - they are a debian derivative and as far as possible, the patches will be generated and maintained by automated scripts. The patches will need maintenance *only* when the package itself is updated in Debian or when emdebian needs to make an interim release of our own. The composite method avoids any need to patch existing Debian programs like dpkg-*. Using apt-cross and a few other scripts from the emdebian tools repository, the only changes required to build an emdebian package from a debian one are within that specific package itself. > > Then we will have our first emdebian package in the > > target repository. > > The problem is that we do already have around 50 in our target > repository, and now approaching a buildd setup ;) ? reprepro doesn't know of any. There are no packages in the emdebian target repository, just the tools. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpwHHQ23bgYw.pgp
Description: PGP signature