rebuilding from old cvs tags

[Dennis Gilmore]

On Tuesday 26 February 2008, Mike McLean wrote:
> I ran into an interesting problem while replicating some older Fedora
> builds in a test environment. Consider this build:
>
> http://koji.fedoraproject.org/koji/buildinfo?buildID=6144
>
> It was built by task 1648 using this cvs url:
> cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/sparse/devel#sparse-0_3-1_fc7
>
> The problem is that if you rebuild this now, you get DIST=fc9, because
> devel has moved on. In my case, I am replicating the buildroot, which
> includes the package that provides the original DIST=fc7. This leads to
> a mismatch. Koji thinks it is building sparse-0.3-1.fc9, but the actual
> result is sparse-0.3-1.fc7. The build completes but import fails. I'm
> trying to reproduce the build as closely as possible, so I want .fc7,
> not .fc9.

I ran into the exact same issue when  i was doing the same thing.

> It occurred to me that Makefile.common could be smarter about this. When
> you checkout a specific revision with cvs, that revision is noted in
> CVS/Tag. It would be possible (though perhaps messy) for Makefile.common
> to note this and behave a little differently.

we probably want to keep in cvs the version of common that was in the tree at 
tag time.  then checkout the same version of common  then it will do the 
right thing (tm)  

> Why? Better repeatability. If you checkout a specific revision from a
> time when dist has a different value, you probably ought to be using
> that dist and not the current one.
>
> I suppose the real problem is that although we're building from a
> specific revision of the main checkout, we're always using the HEAD of
> common. Solving that even more of a mess though (and even if we do, we
> still have a whole bunch of builds from unrecorded revisions of common
> in the system).
>
> So what do folks think? Am I crazy? Would a Makefile.common patch for
> this be welcome?
A patch would be welcome for it.   its something i've been meaning to look at 
for awhile now.  Just to make sure that you can always do a make srpm and get 
a srpm  out that matches.  Ive considered the idea of having a web app to 
make srpms on demand for people also.  It would most likely be needed there 
also.  But it doesnt help with the historical data we dont have.  

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-buildsys-list/attachments/20080226/31554b2d/attachment.sig>