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

[Nils Philippsen]

On Mon, 2008-07-14 at 08:28 -0800, Jeff Spaleta wrote:
> On Sun, Jul 13, 2008 at 9:39 AM, Les Mikesell <lesmikesell at gmail.com> wrote:
> > As long as the old method continues to work, what's the problem with adding
> > a way to improve it going forward?
> 
> 
> Yes, clearly there will need to keep something similar to the "old
> method" around for dealing with tarball releases while this new
> process moves forward.  If we make the change, we'll have to support
> both ways of doing it, and track the update on the new process on a
> package by package basis.
> 
> My largest concern continues to be source distribution. If we have to
> support both models of packaging source control then I'm not sure what
> our source distribution ends up looking like. Is it a mix of exploded
> branches and srpms?

IMO it should be SRPMS that contain a set of individual patches, just as
what we have right now.

> I'd also need to get an idea of what our local patchsets would look
> like in the new cloned vcs packaging. I've had people tell me that
> they very much prefer the style of different patch files as shipped in
> our srpm delineated based on purpose and not necessarily a single
> merged patch file that includes multiple changes. We are starting to
> see the single patch files which are multiple patches merged into a
> single patch  and I've had someone complain specifically about it
> being more difficult to understand.

It should be possible (see Doug's comments about how kernel does it this
way) to generate individual patches on top of a pristine tarball out of
say a git repository. For packages that opted for this scheme, they
could have their exploded repository which e.g. contained individual
branches for each logical patch (stable and experimental ones), where
you could cherry-pick the desired patches into a package release branch
and have some tools that generated the patch files out of that (and
possibly import it into the dist VCS which contained spec files and
patches as usual).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011