On 05/26/2010 10:10 AM, Alan Franzoni wrote:
Hello,
I've just discovered a rather strange glitch with koji, used for
internal builds.
I've set it up by following the wiki instructions, and it seems to work
pretty well, but I've found out a strange behaviour.
I've set up a build tag (something like myproject-build) for arch x86_64
only, and I've added some externals repo to it (notably
centos-x86_64-updates and centos-x86_64-os).
Centos/RHEL (not sure about Fedora) does something tricky BTW: on 64 bit
systems, some packages (notably glibc and other low-level system
packages) are installed for both supported archs (x86_64 and i386). But
the koji "merged" repository xml only includes x86_64 packages; this is
a problem when trying to build some packages explicitly relying on the
presence of such i386 version.
The "mergerepos" tool used by Koji explicitly filters out packages of
other arches. So regardless of what the external repos contain, the
merged Koji repo will contain only x86_64 and noarch packages. Koji
does not support building in a multilib environment.
In order to build 64-bit packages that require 32-bit libs, a special
"glibc32" package is used in Fedora Koji.
http://koji.fedoraproject.org/koji/buildinfo?buildID=153452
This is a 64-bit package, but contains 32-bit headers/libs for
compiling/linking against. You may be able to reuse this in your Koji
environment.
Also, I sometimes use the koji repo on testing machines to fetch the
latest version of my development packages along with os deps. Even tough
mash is probably the best tool for such job, it was quite useful, but
this is impossible when glibc updates happen -> trying to upgrade the 64
bit glibc version but retaining the old version for 32 bit generates a
rpm conflict.
Any clue? Is such behaviour intentional?
It is intentional. Koji always builds in a single-arch environment.
Any multilib setup needs to be done after the build, when assembling a
repo or distro. This is what mash is for.