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.
--
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
