`So I got koji all installed, building stuff, happy days! (thanks
Dennis for all the help via IRC). Now I have a problem. The goal of
the installation is to be able to track and build various binary
content, not take over our entire repo management functionality. I
need to support multiple minor RHEL releases, so I set up two
independent tags with RHEL 5.3 and 5.5, each with their own external
repo with the right content. I then had a database problem when I
tried to build 5.3 content, as I was trying to put another copy of the
'filesystem' package into the rpminfo table with the same NEVR that
was there in 5.5.
So I added tag inheritance, with 5.5 as the parent and 5.3 as the
child. This got around the DB issue fine. Then I built glibc for 5.3
in order to backport a data corruption bugfix (thankfully very rare,
but we've seen it) which was fixed in 5.5. Imagine my surprise when I
then went to do a 5.5 build, and my custom glibc (which is older than
the one in 5.5 - it has the same release as the base 5.3 one and .xyz1
added after it) got used in the buildroot rather than the one from the
external repo with a newer NEVRA!
Dennis tells me that this is expected behavior, tagged builds take
precedence over external repos. For the "distro buildsystem" use case,
that makes sense. But for an enterprise use case, where basically what
we want is to track builds and what was in buildroots, and to ensure
reproducibility of builds, using an "older" package in a buildroot
when a newer one is available somewhere doesn't seem to make much
sense.
Thoughts?
Show replies by thread