Re: Cross-compiling a package that build-depends on Python
Hi,
thanks to pabs for making me aware of the question. I'm cross posting it
to d-cross@l.d.o as that is the proper place for these questions.
On Fri, Feb 02, 2018 at 02:01:30PM +0100, Lukasz Walewski wrote:
> I maintain a binary package that is not part of Debian (yet). The upstream
> content is developed for amd64 and armhf architectures and distributed using
> git. I build the package using git-buildpackage and pbuilder/pdebuild on an
> amd64 build machine with native (i.e. amd64) pbuilder. Obviously, when
> building for armhf, I am cross-compiling.
It's great to hear that cross compiling is starting to just work in some
contexts.
> Recently the upstream development introduced a compile step that requires
> some source files to be pre-processed with a Python script (shipped with the
> sources). I thus added python-all to my Build-Depends field and the native
Why do you use python-all? If python is simply used as a build tool, you
don't need all versions of python. A single version should be
sufficient. Preferably, you use python3 here.
> build works fine again. However, the cross-build doesn't work because the
> postinst script of the python-minimal:armhf package tries to execute the
> armhf python2.7 binary on my amd64 pbuilder:
>
> $ pdebuild -- --host-arch armhf
> [...]
> Setting up python2.7-minimal:armhf (2.7.13-2+deb9u2) ...
> /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
> /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: Exec format error
> dpkg: error processing package python2.7-minimal:armhf (--configure):
> subprocess installed post-installation script returned error exit status 2
> dpkg: dependency problems prevent configuration of python-minimal:armhf:
> python-minimal:armhf depends on python2.7-minimal (>= 2.7.13-1~); however:
> Package python2.7-minimal:armhf is not configured yet.
>
> dpkg: error processing package python-minimal:armhf (--configure):
> dependency problems - leaving unconfigured
> Errors were encountered while processing:
> python2.7-minimal:armhf
> python-minimal:armhf
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> E: Failed to process build dependencies
> E: pbuilder-satisfydepends failed.
python is quite unique in this respect. Installing it requires executing
python and unlike perl it can be installed for foreign architectures in
theory. As you noticed, this doesn't work practically.
> What is the correct way of handling this scenario?
The question to think about is: What do you need python for?
Often enough the answer is "it is executed during build, but the
resulting .deb does not integrate with python in any way". That answer
translates to "you want the build architecture python". On the other
hand, if the resulting .deb ships a python extension, the answer
translates to "you want the host architecture python".
All Build-Depends are treated as host architecture by default. In this
case, it seems very likely that python is a build tool so you
(implicitly) requested python for the wrong architecture. Switching a
dependency from host architecture to build architecture happens by
annotating it with ":native" (<- only works in Build-Depends, not
Depends).
Practically, whenever you see python{,3}{,-all}{,-dev} in Build-Depends
you can already tell that your package won't cross build. Often times
annotating the dependency is correct, but for python-dev the fix often is
s/python3?\(-all\)?-dev/lib&, &:native/g instead.
I wonder whether we should turn this into a lintian warning. The
presented solution is somewhat incomplete. If you also list some python
module in Build-Depends, things become difficult and there is no
straight forward fix. Sometimes (e.g. python3-six) the module is marked
Multi-Arch: foreign and the approach keeps working, but for e.g.
python3-mako we already have no solution despite it being very common
(via gobject-introspection).
Hope this helps. If it doesn't, please continue at d-cross@l.d.o.
Helmut
Reply to: