On Fri, 2008-07-11 at 19:04 -0400, Jesse Keating wrote:
On Fri, 2008-07-11 at 14:57 -0800, Jeff Spaleta wrote:
Okay.. the important bit I was missing was making sure 'we' keep a
local clone of the source for everything we are building and
and we weren't just pulling dynamically from upstream at build time.
A "clone" would only work for a very very small portion of our
Any upstream project using git, hg, and maybe svn can do this. That
by no means, a very very small portion of software.
More likely would be taking their tarball release and checking it
source code. Essentially turning our lookaside cache from a
tree of tarballs to a SCM tree of modules. However since I don't
you can reasonably explode a tarball, check it into SCM, check it
out and tar it up again and expect the checksums to match that of the
upstream tarball release.
If you have a cloned repo (Note: CVS does not qualify as this) then
don't need a tgz with matching checksums. The check against upstream
can be a check against the upstream source revision.
I sent some stuff to Jef under separate cover, but one of the things I
pointed out in an email was this
An SRPM is just a container, one that produces source in the end.
an SCM repo that takes you directly to the source in question
generating the source in question is merely cutting out the middle
So, obviously, the same is true of tarballs. If you are going to do a
package as an exploded source repo, then you need to get the idea
straight right now that the tarball becomes totally, and completely
irrelevant. It's all about the repo. A tarball is something you hand
off to poor saps that haven't joined the 21st century, all the while
snickering at their inability to get with the times. It is nothing
than a middle man step that interferes with efficiency of operation
that should be cut out of the loop. Instead, you use other means of
verifying your initial upstream source matches upstream. Git has an
extremely strong version of this built in, other repos don't but means
could be scripted to get at the information you want.
For that reason I picture two things. One, the pristine tarball
checked into SCM, and an exploded view of it checked in and updated
new releases happen. The (s)rpms we build would be built from the
pristine tarballs, the exploded view would just offer a convenient
method of developing on them. Not exactly all that useful/desired in
Fedora land where we're UPSTREAM UPSTREAM UPSTREAM, but useful for
things like EPEL where version changes are less than welcome.
Ick. Anyone who wastes their time doing this is deserving of what
If upstream *only* does tarballs, and has no version control (or only
CVS version control), then you can check the tarballs into an SCM or
look aside cache, but there is no reason to have both exploded source
and tarballs around.