Colin Watson <cjwat...@ubuntu.com> writes: > On Wed, Nov 04, 2009 at 01:27:26PM +0100, Simon Josefsson wrote: >> Colin Watson <cjwat...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
