Heads-up: brand new RPM version about to hit rawhide

Jesse Keating jkeating at j2solutions.net
Sat Jul 12 02:41:47 UTC 2008





On Jul 11, 2008, at 21:29, Doug Ledford <dledford at redhat.com> 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




More information about the fedora-devel-list mailing list