On Tue, 2008-09-09 at 09:46 -0700, Jesse Keating wrote:
> On Tue, 2008-09-09 at 18:03 +0200, Denis Leroy wrote:
> >
> > There's no logic here. You're not forcing people to tag after every CVS
> > check-in, as far as I know. If a release 'n' fails to build (for
> > example, because you forgot to check-in a patch), it makes zero sense to
> > bump to n+1, because release 'n' never *existed* in the first place,
> > since it was never built. That has zero impact over auditing. Spec file
> > auditing is done through CVS.
>
> The audit part is something of a red herring. The GPL compliance part
> is what is bothersome. If we want to save archive space by relying on
> re-generating srpms of shipped binaries on demand, we need to ensure
> that CVS tags don't change over time. For better or worse, we build
> from CVS tags, so to get the source that matched the build, we have to
> checkout via CVS tags. If those tags can change over time, the trust
> level is gone. That's why there is a push to make the tags immutable,
> or at least the successfully built tags immutable.
>
> Personally I just want to move off of CVS and off of building from tags,
> and instead build from something inherently immutable, like the shasum
> of the repo at a given time.
>
> MikeB said that he'd look into some CVS/make changes that would allow
> checking koji for an on going or successful build of a tag/n-v-r before
> allowing a force-tag. This would allow folks to force-tag before having
> a successful build, but would not allow you to force the tag after a
> successful build, or while a build is still going with that n-v-r.
>
> I think this approach, while it may slow down force-tags and prevent
> force-tags during any koji outage, will give us the best of both worlds.
Of course, a relatively minor change would eliminate this problem. If
you just modify koji to treat any build command that uses a branch name
instead of a specific revision tag to mean HEAD of that branch, then you
can have it download the HEAD of the branch, check the n-v-r in the spec
file, check for a conflicting tag already in the repo and bail if found,
if not found perform the build, if build succeeds, koji adds n-v-r tag
to repo, if build fails, tag still absent. If you want to build a
specific non-HEAD build, you just pass in an already existing tag, koji
treats it as a rebuild and builds the package accordingly and makes no
effort to put the tag into the repo.
Really, we shouldn't be tagging at all if the purpose of a tag is to
mean "This is the exact source code we built through the build system".
Koji knows that just as well as we do, and koji can enforce the
correctness and immutability of it without having to worry about CVS
tricks or anything like that.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
