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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
