[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-checkbuilddeps wrapper for dpkg-cross, round 2

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.


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

Attachment: pgpwHHQ23bgYw.pgp
Description: PGP signature

Reply to: