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