Re: Arch: any Packages (Test::Valgrind)
Hi Jonas, and all:
I e-mailed Vincent directly and he said:
"Technically, it's a pure perl module. The XS file is indeed only used
for testing, and it's only build if there's an available C compiler.
So you don't need it at all for using the module, or even for testing
it."
So I propose we move it to an Arch: all package, which should fix our
FTBFS errors (except where valgrind itself is broken, but that's the
responsibility of the valgrind maintainer, rather than
us/libtest-valgrind-perl).
Cheers,
Jonathan
On Mon, Nov 30, 2009 at 11:08 AM, Jonas Smedegaard <dr@jones.dk> wrote:
> On Mon, Nov 30, 2009 at 10:49:53AM -0500, Jonathan Yu wrote:
>>
>> On Mon, Nov 30, 2009 at 6:04 AM, Jonas Smedegaard <dr@jones.dk> wrote:
>>>
>>> Hi Jonathan (and others),
>>>
>>> On Mon, Nov 30, 2009 at 12:28:57AM -0500, Jonathan Yu wrote:
>
>>> 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.
>>
>> True.
>>>
>>> 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.
>
> Whether or not _valgrind_ fails on some archs is for valgrind itself to deal
> with, not your Perl wrapper.
>
> As a comparison, it might be that docbook has a bug that causes some
> documentation package to render its images wrongly when built on some archs
> - but generating that documentation multiple times is insane, as that would
> imply that all other -doc packages should perhaps also build arch-dependent
> "just to be on the safe side". The sane approach was for docbook to include
> a testsuite that verifies once per arch at build time (and then throws away
> the result) that all features of that package works as intended for that
> arch.
>
>
>>> 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.
>
> md5sums will only tell you that something is different - make diffs to
> figure out _what_ is different (in non-binary chunks) to be able to make a
> qualified judgement if the changes are important (i.e. variations in spacing
> is often irrelevant but cause md5sum mismatch).
>
>
> Kind regards,
>
> - Jonas
>
>
> P.S.
>
> Please do not cc me - I am subscribed to the list (and adding me explicitly
> confuses my MUA sorting routines).
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
>
> [x] quote me freely [ ] ask before reusing [ ] keep private
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLE+4NAAoJECx8MUbBoAEhV0MQAJIEDjoAGSDzpgtMr0vFWmsB
> YtapOe0Ri7sR5jBUUaCRaLXU0ns3W89KNIEkK3sl06elwghX7wt7biWJxoovGohA
> RG+2V/0YOtc5EvEnx/Uu41x0WDJsU+Yp0/LSe21t7IUvLCeyhIqyy4BwiPVQ0gQ0
> Hg8ZJGW8Yj6RbPMtqvOGGIw7VhByY5I2xkjVEMrKNuzChSxuvirnGBG2XTSuWvu4
> P4KM/jiHiijGUdx28WtFlaFW7M1mRH0veQMpTgkjYJy/8kp1bE88QvEMZ+4fotoA
> D08dCfko9x/5uudaePYKEmWbHEOXQSFG/lrh6y62vbXW8Lx1FE1Nel46ou4LQ7vK
> 6GRhC5M7qwvDZ2D6RflgswbNEA1ZvZ684prL4a65doLw9Fq6ZHcnkj1PGu0pc0hy
> CTM/8+wzJGr4aM7HVWv80Goz8IMiNXQWgSFNxKo0kksrdATAkP2P4aUW2uoncj1+
> UW8ECo6vVTw7EsJcg8ilWEmm1Lhz3ZbaQp3mk6lhVWl8B3xPUbE5pNpPmhCUMCAz
> JKSXlMZTtLoFcCW/RF9a2uc1Ejx+lGyiBS0Y4Dkbthigu6JoUmspOwS+e/1kQZ69
> kOQWqp1/IjLU9CbnL7JxARpzbLkZP3YHJWvQWU9JVhPm7GMbqJzGJMnAcnpPZNdi
> PRyBQOTHq/reHizwlb8S
> =e2f/
> -----END PGP SIGNATURE-----
>
>
Reply to: