FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Build System

 
 
LinkBack Thread Tools
 
Old 12-01-2010, 03:05 PM
Jon Stanley
 
Default koji using older packages in buildroots when build exists and external repos are used

`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?
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 12-02-2010, 04:26 AM
Florian La Roche
 
Default koji using older packages in buildroots when build exists and external repos are used

> Thoughts?

Instead of using tagging at all, can you use only repos to
specify the different needs of your koji setup? Then you
get that behaviour where yum selects the newest rpm, right?

regards,

Florian La Roche

--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 12-02-2010, 11:13 AM
Jon Stanley
 
Default koji using older packages in buildroots when build exists and external repos are used

On Thu, Dec 2, 2010 at 12:26 AM, Florian La Roche
<Florian.LaRoche@gmx.net> wrote:

> Instead of using tagging at all, can you use only repos to
> specify the different needs of your koji setup? Then you
> get that behaviour where yum selects the newest rpm, right?

Yeah, but you have to tag stuff at some point, or just use scratch
builds, right? Scratch builds get reaped after some time (at least in
the Fedora buildsystem, and I'm not sure where/how to configure that
behavior) and aren't nearly as easy to find as "real" builds. How I've
gotten around it for now is that I've got a dist-rhel55 and
dist-rhel53 tags, with dist-rhel53-build and dist-rhel55-build as
build tags. When I do a build, I'll then either build the 5.5 version
of the same thing, or I'll untag the package, then tag it with an
'updated-content' tag, which doesn't get used anywhere.
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 12-02-2010, 02:07 PM
Mike Bonnet
 
Default koji using older packages in buildroots when build exists and external repos are used

On 12/02/2010 07:13 AM, Jon Stanley wrote:
> On Thu, Dec 2, 2010 at 12:26 AM, Florian La Roche
> <Florian.LaRoche@gmx.net> wrote:
>
>> Instead of using tagging at all, can you use only repos to
>> specify the different needs of your koji setup? Then you
>> get that behaviour where yum selects the newest rpm, right?
>
> Yeah, but you have to tag stuff at some point, or just use scratch
> builds, right? Scratch builds get reaped after some time (at least in
> the Fedora buildsystem, and I'm not sure where/how to configure that
> behavior) and aren't nearly as easy to find as "real" builds. How I've
> gotten around it for now is that I've got a dist-rhel55 and
> dist-rhel53 tags, with dist-rhel53-build and dist-rhel55-build as
> build tags. When I do a build, I'll then either build the 5.5 version
> of the same thing, or I'll untag the package, then tag it with an
> 'updated-content' tag, which doesn't get used anywhere.

I think the inheritance between your 5.3 and 5.5 tags are the problem,
but I'm having a hard time visualizing the tag layout you described.
Could you include the output of "koji list-tag inheritance" for your 5.3
and 5.5 build tags? We may be able to be more help then.
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 12-03-2010, 11:39 AM
Jon Stanley
 
Default koji using older packages in buildroots when build exists and external repos are used

On Thu, Dec 2, 2010 at 10:07 AM, Mike Bonnet <mikeb@redhat.com> wrote:

> I think the inheritance between your 5.3 and 5.5 tags are the problem,
> but I'm having a hard time visualizing the tag layout you described.
> Could you include the output of "koji list-tag inheritance" for your 5.3
> and 5.5 build tags? *We may be able to be more help then.

Sorry for the delay in response, can't really copy and paste from my
koji instance to gmail

$ koji list-tag-inheritance dist-gslinux55
dist-gslinux55 (1)
u2514u2500dist-gslinux53 (2)
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 12-06-2010, 07:50 PM
Mike McLean
 
Default koji using older packages in buildroots when build exists and external repos are used

On 12/02/2010 07:13 AM, Jon Stanley wrote:
> Yeah, but you have to tag stuff at some point, or just use scratch
> builds, right?

You can tag builds without using a tag that causes them to be picked up
by the buildroot.

> Scratch builds get reaped after some time (at least in
> the Fedora buildsystem, and I'm not sure where/how to configure that
> behavior) and aren't nearly as easy to find as "real" builds.

koji leaves it to the administrator to clean out the scratch build
directory. Most accomplish this with a simple cron script.

Of course, if you're using koji-gc then even "real" builds can get
reaped, depending on your gc policy.

> How I've
> gotten around it for now is that I've got a dist-rhel55 and
> dist-rhel53 tags, with dist-rhel53-build and dist-rhel55-build as
> build tags. When I do a build, I'll then either build the 5.5 version
> of the same thing, or I'll untag the package, then tag it with an
> 'updated-content' tag, which doesn't get used anywhere.

Depending on how often you want to override builds in the external repo,
you might go with an inheritance like this

dist-rhel55-build
* (external 5.5 repo)
- dist-rhel55-override

dist-rhel55
(no inheritance)

target dist-rhel55 uses dist-rhel55-build
target dist-rhel55-override uses dist-rhel55-build


...and similar for 5.3.
With a setup like this, your buildroots only have the external repo rpms
and those that you have explicitly tagged (or built) in the -override tag.

On the other hand, if you want to override/add-to most of the time, you
could do something like this:

dist-rhel55-build
* (external 5.5 repo)
- dist-rhel55

dist-rhel55-nobuild
- dist-rhel55

target dist-rhel55 uses dist-rhel55-build
target dist-rhel55-nobuild uses dist-rhel55-build


--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 

Thread Tools




All times are GMT. The time now is 05:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org