[csw-maintainers] GAR: archall - a new checkpkg module
hson at opencsw.org
Fri Feb 5 09:00:09 CET 2010
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
diff -r i386/include/ImageMagick/magick/magick-config.h
< /* #undef HAVE_LTDL */
> #ifndef MAGICKCORE_HAVE_LTDL
> #define MAGICKCORE_HAVE_LTDL 1
diff -r i386/include/openssl/opensslconf.h
< #undef DES_RISC1
> #define DES_RISC1
diff -r i386/include/orbit-2.0/orbit/orbit-config.h
< #define ORBIT_ALIGNOF_CORBA_LONG_LONG 4
> #define ORBIT_ALIGNOF_CORBA_LONG_LONG 8
< #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.
More information about the maintainers