Bug#554343: libtasn1-3: don't run tests when cross-compiling

[Simon Josefsson]

Colin Watson <cjwatson at ubuntu.com> writes:

> On Wed, Nov 04, 2009 at 01:27:26PM +0100, Simon Josefsson wrote:
>> Colin Watson <cjwatson at ubuntu.com> writes:
>> > Running tests when cross-compiling doesn't work
>> 
>> Is that something that should be supported by debian packages?
>
> There are a number of different people trying to do cross-building work
> based on Debian. Emdebian is one, of course, and the project I'm working
> on (a relative latecomer) is another. It certainly isn't yet a policy
> requirement, and isn't likely to be for a while, but that's at least in
> part simply because a lot of packages currently fail to cross-build. In
> Debian, policy tends to follow working implementation rather than the
> other way round, so the first step in developing policy around this has
> to be ad-hoc efforts to get the number of working packages up a bit.
>
> Simple packages that just use autotools in the most usual way and don't
> do any fancy packaging stuff do tend to work fine, and there've been a
> lot of cross-build patches accepted already, so we're not entirely
> fighting against the wind.
>
>> I believe many packages will have the some problem, so potentially
>> there is a better way to deal with it than patching each and every
>> package.
>
> I have thought a bit about whether it makes sense to do this in central
> scripts (CDBS, dh_auto_test, etc.). I'm on the fence about that. On the
> one hand, it would certainly be convenient not to need to change more
> packages than necessary. On the other, it would be incorrect to state
> across the board that tests can never be run when cross-compiling; this
> is true when the tests involve running a host architecture binary, but I
> can imagine e.g. tests that just made sure that data files were sane, or
> that kind of thing.
>
> Emdebian's automation sets DEB_BUILD_OPTIONS=nocheck to avoid running
> into this. I think, to be honest, that I may do the same in my
> automation simply because it'll be quicker, but my gut feel is that it's
> more technically sound for packages to declare whether their tests
> involve running host-architecture binaries or not.
>
>> Also, it seems to me that the patch isn't generally the right thing,
>> there are plenty of cross-compilation targets where you _can_ run the
>> binary on the host architecture (i686 on amd64, windows via wine, etc).
>
> While this is true, I don't think many people are doing this kind of
> thing with Debian packages at the moment. That may become more of an
> issue with the second phase of multiarch support in Debian, once it's
> feasible to hook things up so that e.g. ARM binaries are just magically
> run using qemu; but when that happens the cross-building landscape is
> going to change radically anyway, so I'm not really attempting to think
> about that yet.

Thanks for explanation -- I'll defer to the other libtasn1 package
maintainers (who actually are DD's) to decide.  I do think it would be
nice to be able to cross-compile all debian packages though, so I
support your goals.

My feeling is that we should use your patch now, and if there is ever a
problem resulting from it, we'll should feel free to revert it.

(I recall that the libtasn1 self-tests have caught real bugs in the
past, in particular on rare architectures, so disabling it has some QA
cost.)

/Simon