[csw-maintainers] GAR: archall - a new checkpkg module

[Roger Håkansson]

Maciej (Matchek) Blizinski wrote:
> I spoke about this today with
> Phil on IRC, there may be devel packages with architecture related
> settings.  I need to hunt down some of them and build checks based on
> some examples.  

I don't think you can make it totally foolproof unless you have access
to both ARCH-packages and diff them as part of the release procedure.

Example of a couple of cases where it would be almost impossible to
detect using a search for specific 
(BYTEORDER/BYTE_ORDER/ENDIAN/x86/i386/sparc/...) strings

diff -r i386/include/ImageMagick/magick/magick-config.h
sparc/include/ImageMagick/magick/magick-config.h
400c400,402
< /* #undef HAVE_LTDL */
---
> #ifndef MAGICKCORE_HAVE_LTDL
> #define MAGICKCORE_HAVE_LTDL  1
> #endif

diff -r i386/include/openssl/opensslconf.h
sparc/include/openssl/opensslconf.h
200c200
< #undef DES_RISC1
---
> #define DES_RISC1

diff -r i386/include/orbit-2.0/orbit/orbit-config.h
sparc/include/orbit-2.0/orbit/orbit-config.h
23c23
< #define ORBIT_ALIGNOF_CORBA_LONG_LONG    4
---
> #define ORBIT_ALIGNOF_CORBA_LONG_LONG    8
25,26c25,26
< #define ORBIT_ALIGNOF_CORBA_DOUBLE       4
< #define ORBIT_ALIGNOF_CORBA_LONG_DOUBLE  4
---
> #define ORBIT_ALIGNOF_CORBA_DOUBLE       8
> #define ORBIT_ALIGNOF_CORBA_LONG_DOUBLE  8


These differences will most certainly affect how a application compiled 
with those headers, will work.



> 
> More examples of any autodetectible reasons why a binary-free package
> might be architecture-dependent, would be appreciated.

Include files containing BYTEORDER/BYTE_ORDER/ENDIAN/x86/i386/sparc



But one thing I'm wondering about, why are we even bothering trying to 
make the devel-packages ARCHALL? Are we having some kind of problem 
regarding space on mirrors or?

I can't think of any platform that don't have separate devel packages 
for each arch, even those that don't include .a files (which many do).

I think that we might possible get more bugs when some maintainer 
releases a ARCHALL package based on what checkpkg tells him, rather on 
what upstream/autoconf belives to be true.
Also such bugs might be hard to track down.
Lets say package A actually have some arch-dependant stuff and then 
package B is built using some wrong defines from package A. Then the 
maintainer for package B might spend a lot of time tracking down a bug 
which actually isn't a bug in B but a error in the installed files for A.