make force-tag gone

Toshio Kuratomi a.badger at gmail.com
Thu Sep 11 21:47:49 UTC 2008


Jesse Keating wrote:
> Really it comes down to a premature desire to clean up the way that Koji
> builds things.  For lack of something easier, koji builds from a CVS tag
> based on the N-V-R of a package build.  For lack of knowledge of
> something easier, the thought is that tag is the only thing we can use
> to get back to the actual source used for a build.  It's not.  I've been
> told of at least one way to use something different, the CVS/Entries
> file.  Yeah, it might take a little work to cook up an app to go from
> that to the source, but that's fine, that's work the person who wants
> this has to do.
> 
This specific implementation would be a bad thing.  Instead of having a
nice, SCM abstract method of communicating to koji what to build from
(the tag) you'd be resorting to CVS specific knowledge.

> Instead, we're forcing all of our users to change how they work because
> some people feel uncomfortable about something WE'RE NOT EVEN RELYING
> UPON!!  We don't rely upon anything to go backwards at this time.
> Nothing.  I have no objections to finding a way to make absolutely
> certain that what koji builds from is immutable and can be pulled out of
> source control.  No objections at all.  I highly object to forcing our
> users to come up with this for us, because they're so pissed off that
> we've removed tag moving.
> 
> Simply put, figure out a way to meet the immutable requirements first,
> before taking away the ability to move tags forward.  Don't remove that
> ability, and then sometime in the indeterminate future fix the immutable
> problem.

So I see a certain bit of mismatch here between what koji is made to do
and what people want to do.  It's also one of the contributing reasons
we aren't yet building EPEL in koji:

  Reproducibility of Builds

In order for this to hold true, you have to consider the input streams
(cvs, lookaside cache, and download repositories) as part of koji.  If
we could upload new files to the lookaside cache locations or
arbitrarily change what's in the SCM or change the packages in the
repository without koji knowing then koji loses the ability to reprodce
builds.

Note that I think the particular implementation of Makefile.common and
koji forces us into a no-win situation in this.  On the one hand, tags
that go into the buildsystem must be immutable in order for the
reproducibility of builds to be assured.  On the other hand, the tag is
tied to the version and release of the package in such a way that it's
impossible to submit a new build without bumping the version in the spec
file even when no packages were created in the previous run.  We need to
decouple these.  I think it'll require changes to Makefile.common (to
write the tags), CVSROOT/admin/tagcheck (to check for immutability of
specific tags), and koji (to check that the Version and Release in the
spec file isn't currently a building or built package).

-Toshio


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080911/b5dcbf26/attachment.sig>


More information about the fedora-devel-list mailing list