Bug#771496: dpkg-cross follow-up
Hi Neil,
Thanks for taking the time to respond.
On Sat, Jan 03, 2015 at 06:31:38PM +0000, Neil Williams wrote:
> > You are missing an important aspect here: dpkg-cross is currently the
> > only way to build a cross compiler from src:gcc-4.9.
>
> Sorry, I did not miss that aspect: your statement is incorrect.
I see that there is need for differentiation here. The statement is
indeed too broad, but there still is some truth in it.
> Clean pbuilder sid chroot:
>
> # dpkg --add-architecture armhf
> # apt-get -qq update
> # apt-get build-dep cross-gcc-4.9-armhf
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following NEW packages will be installed:
> autoconf autoconf2.64 autogen autotools-dev
> binutils-arm-linux-gnueabihf bison bsdmainutils chrpath cross-gcc-dev
> debhelper diffstat expect file flex gawk gcc-4.9-base:armhf
> gcc-4.9-source gdb gettext gettext-base groff-base guile-2.0-libs
> intltool-debian libasprintf0c2 libbison-dev libc6:armhf libc6-dev:armhf
> libcloog-isl-dev libcroco3 libexpat1 libffi6 libfl-dev libgc1c2
> libgcc1:armhf libglib2.0-0 libgmp-dev libisl-dev libltdl7 libmagic1
> libmpc-dev libmpfr-dev libopts25 libopts25-dev libpipeline1
> libpython-stdlib libpython2.7 libpython2.7-minimal libpython2.7-stdlib
> libsigsegv2 libssl1.0.0 libtcl8.6 libtool libunistring0 libxml2
> linux-libc-dev:armhf m4 man-db mime-support netbase patchutils
> po-debconf python python-minimal python2.7 python2.7-minimal quilt
> realpath sharutils systemtap-sdt-dev tcl-expect zip zlib1g-dev
>
> dpkg-cross is not mentioned in that list. Not only is it not the only
> way to build a cross compiler from src:gcc-4.9, it is not even the
> default way to build a cross-compiler from src:gcc-4.9.
What is in the list though is cross-gcc-dev, which is a heavy patch
pile. This is nowhere close to be the default for building cross
compilers from src:gcc-4.9. In fact, it is so non-default that the gcc
maintainer seeks to remove these packages: #771070.
> Nothing about
> building a cross-compiler or using a cross-compiler on Debian unstable
> has to have anything at all to do with dpkg-cross - except that
> some packages need data from those config files. Even that can be
> patched in locally if someone has need. Such steps are a lot less work
> than has been required to get packages to cross-build previously.
Ironically, I have to agree here: Nothing about building a cross
compiler needs dpkg-cross. What you do need dpkg-cross for however is
satisfying the Build-Depends of src:gcc-4.9. After setting a target and
regenerating debian/control, it does build-depend on e.g.
libc6-dev-armhf-cross which is nowhere to be found and only obtained by
running libc6-dev:armhf through dpkg-cross. So actually, you need
dpkg-cross before building a cross compiler unless you apply heavy
patches.
Also note that the heavy-patching method of building a cross compiler
has some drawbacks at the moment:
* bootstrapping does not work. #774010 (patch available)
* Various multilib issues. For powerpc I managed to understand one
#774356, but other architectures still fail.
* Current buildds do not run a version of sbuild that is capable of
building e.g. cross-gcc-4.9-armhf. (jessie sbuild is fixed)
* britney cannot migrate these packages due to cross-arch dependencies.
(Wookey is working on a solution.)
None of the above applies to the supported method (which involves
dpkg-cross).
> 2: the problems of cross-building on jessie have been well known since
> the wheezy release and all the work went into trying to get the correct
> methods working.
It is funny that you paint the heavy patching method as "correct" while
there is bitter disagreement about which method actually is to be used.
> My personal feeling is that dpkg-cross never deserved to be in the main
> archive - it should have stayed in the Emdebian toolchain repositories
> - but I was not involved in dpkg-cross at that time, I had to work with
> it where was. As I've already said, it was never possible for
> dpkg-cross to be Policy compliant. It is designed to break Policy. The
> irony is that it will finally be removed from testing for doing
> explicitly what it was designed to do. That is fine by me, I wanted it
> gone a long time ago.
I think that there is quite a big difference between a package that does
not comply with the policy and a tool that produces non-compliant
packages. I acknowledge that dpkg-cross produces non-compliant packages
and always did so. However, users have the general expectation that
packages in the archive adhere to the policy no matter what they are
useful for and we should keep up that promise. In a similar vein, we do
not expect packages generated by equivs to adhere to the policy, but we
do expect equivs itself to comply.
Helmut
Reply to: