On Jul 11, 2008, at 21:29, Doug Ledford <dledford@xxxxxxxxxx> wrote:
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
packaging
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
software.
Any upstream project using git, hg, and maybe svn can do this. That
is,
by no means, a very very small portion of software.
More likely would be taking their tarball release and checking it
into
source code. Essentially turning our lookaside cache from a
directory
tree of tarballs to a SCM tree of modules. However since I don't
think
you can reasonably explode a tarball, check it into SCM, check it
back
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
you
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
-----paste
An SRPM is just a container, one that produces source in the end.
Using
an SCM repo that takes you directly to the source in question
instead of
generating the source in question is merely cutting out the middle
man.
-----end paste
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
more
than a middle man step that interferes with efficiency of operation
and
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
itself
checked into SCM, and an exploded view of it checked in and updated
as
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
they
get.
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.
Unfortunatly I live in reality where many upstreams post process the
scm checkout so reliance on the scm alone is not possible.
--
Jes
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
