Different packages in i386 and x86_64 repositories

I have found, that some packages are only in one arch repository and not in the second one and one package have different version:

http://updates.interworx.info/iworx/RPMS/cos4x/x86_64/
http://updates.interworx.info/iworx/RPMS/cos4x/i386/

SpamAssassin-3.0.3-100.rhe4x.iworx.x86_64.rpm
SpamAssassin-tools-3.0.3-100.rhe4x.iworx.x86_64.rpm

  • in i386 is version 3.0.2

mysql-shared-compat-4.0.21-100.iworx.i386.rpm
ripmime-1.4.0.3-100.rhe4x.iworx.i386.rpm
yum-conf-1.0-101.rhe4x.iworx.noarch.rpm
yum-headers-1.0-100.rhe4x.iworx.i386.rpm

  • are only in i386 folder, not in x86_64

perl-DB_File-1.810-1.rhe4x.iworx.x86_64.rpm
perl-Digest-HMAC-1.01-1.rhe4x.iworx.x86_64.rpm
perl-MIME-Base64-3.05-1.rhe4x.iworx.x86_64.rpm
perl-PodParser-1.28-1.rhe4x.iworx.x86_64.rpm

  • are only in x86_64 folder, not in i386

Missing binaries:
analog
curl
ipvsadm
libcurl2
libcurl3
libssh2
mysql
perl-ANSIColor
perl-TermReadKey
rrdtool

  • are only in srpms, not in binaries. These packages are maybe not used for CentOS4. If so, this is no problem.
    Just may be better for the future to have separate SRPMS repositories for every distro.

Martin Kuchar

Martin,

Every SRPM there can be used for every distro but we only provide what the distro itself needs. Having separate SRPM dirs would mean duplicating SRPMs that are the same, which doesn’t make much sense and just wastes space. The system isn’t condusive to 3rd parties building RPMs since we don’t any docs on our “system” and we may at some point to make building easier.

You’ll also note some of the “missing” rpms are noarch, and are shared between all distros.

Finally, the version difference is due to some naming conflicts with spamassassin and will be fixed soon.

Chris