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