Re: Arch: any Packages (Test::Valgrind)
On Mon, Nov 30, 2009 at 6:04 AM, Jonas Smedegaard <firstname.lastname@example.org> wrote:
> Hi Jonathan (and others),
> On Mon, Nov 30, 2009 at 12:28:57AM -0500, Jonathan Yu wrote:
>> Here's the thing--
>> During the build of Test::Valgrind, it builds an .xs file into a C
>> file. This is then used for testing the leak detection functions.
>> As far as I can tell, this file isn't actually used except during
>> build. It's compiled, tested (with the current system valgrind) and
>> then the other files (ie, not Valgrind.so) are installed. This means
>> the file doesn't actually contain any arch-dependent stuff. Actually,
>> I think Test::Valgrind works by forking valgrind (an Arch: all thing)
>> and parsing its output. So once installed, I think it qualifies as
>> Arch: all.
>> Here's the concern: do we want to do arch: any anyway, so that the
>> buildds each test the module with *their* particular built
>> Valgrind.so? It's not installed, after all, but in this case I think
>> things are a bit ambiguous...
> I fail to understand: You write above that valgrind is arch all (which in
> itself sounds odd - isn't it C of C++ code?) and then talk about comparing
> against a shared object from that arch all package?!?
You are correct, valgrind is Arch: any. That was a typo.
Test::Valgrind builds an .so during build time, and uses it for
testing, but it doesn't install it since it isn't used afterward.
>> Any input is welcome and appreciated. Right now I think it belongs as
>> Arch: all, but I'm not totally sure (and as mentioned above, there are
>> reasons to declare it Arch: any and override, or move stuff into
>> /usr/share rather than /usr/lib).
> Build tests in Debian packages do not test if all is possible on all
> architectures. As an example, it is not verified if documentation can be
> built on all platforms - it is only built once.
> So it seems to make most sense to me to *not* build on all archs if the
> resulting package is identical on all archs.
That's the question, I suppose. From a cursory look, it *does* build
the same on all arches, but I think the tests might fail on some
platforms while they pass on others. This is why I was considering
Arch: any, so at least we'd get FTBFS errors and know which dists
don't like valgrind.
> Beware, that it is not only a matter of the resulting package containing
> binary stuff or not - if part of the package e.g. contains some lists of
> numbers tat are architecture-specific (that is crucial for its
> functionality, not just in documentation or similar) then it is *not*
> identical across archs and should be arch any.
I don't believe they do, but I haven't looked in depth yet. I'll take
a closer look and get md5sums later to compare them all.