[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 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

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

Given this Build-Depends line:

Build-Depends: debhelper (>=, zlib1g-dev | libz-dev,
autotools-dev, libreadline5-dev | libreadline-dev, binutils (>=

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 (>=, zlib1g-dev | libz-dev,
autotools-dev, libreadline5-dev | libreadline-dev, binutils (>=
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

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

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

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

Attachment: pgpt49Efs9LrG.pgp
Description: PGP signature

Reply to: