Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Wed, Nov 19, 2014 at 6:05 PM, Don Armstrong <don@debian.org> wrote:
> On Wed, 19 Nov 2014, Ben Longbons wrote:
>> The code I work on isn't packaged for Debian yet, but without having
>> cross-compilers to play with, I will *never* be able to support
>> anything other than x86-*.
>
> Which suite are you currently using? I'm asking, because I want to know
> whether actually just doing this for jessie is enough, or whether doing
> this for unstable is enough, or whether we have to do it for jessie and
> unstable and then get a complete, tested, multiarch procedure which
> works in Debian which is acceptable to both porters and the gcc
> maintainers.
Our production server runs stable (i.e. Wheezy now, but we plan to
upgrade not long after Jessie is released), and by sanity the CI
server runs the same as production (and currently does x86-* builds
only since there are no cross tools in Wheezy).
My dev machine runs testing (Jessie), but it is *very* common for CI
to catch errors that I can't, due to tiny differences between versions
(gcc-4.7 4.7.2 in Wheezy has a frustrating bug with arrays of string
literals but gcc-4.7 4.7.3 in Jessie was fine; the Debian-specific
packaging bugs in libstdc++-dbg that have regressed in *every* new gcc
release; several subtle between gdb versions (e.g. printing null
pointers as '0' instead of '0x0' and breaking my script that checks
gdb output) and of course the catastrophic bug #748711 (at least
there's a migration plan for Stretch now (gdb-python2 package in
experimental))).
So, if you want upstream and Debian maintainers to support a package
in $suite, you need the full set of cross tools and multiarch libs in
$suite, not just in unstable. I've proven with the cross tools in
unstable that my program *should* work on non-x86-* platforms, but
real-world reports indicate that it does *not* on stable (Wheezy), on
at least one architecture.
If the cross tools miss jessie and go in jessie-backports, that will
require a significant amount of knowledge and discipline on the part
of all the package maintainers involved, to make sure that they always
have matching versions despite being in different repos or they will
not be useful for package developers. If they are treated as one
package and go in one repo, everybody is happy.
-Ben
Reply to: