The Future of Fedora Package Management and the RPM Philosophy

[Toshio Kuratomi]

On Sat, 2007-06-09 at 10:04 -0400, Simo Sorce wrote:
> On Fri, 2007-06-08 at 14:31 -0500, Jeffrey C. Ollie wrote:
> > On Fri, 2007-06-08 at 15:11 -0400, Jesse Keating wrote:
> > > I have to question why the build would have to be this way?  If you've got the 
> > > prestine source branch, and you've got the patch branches, is there no way to 
> > > extract the patches to such a format that they will apply to the prestine 
> > > source, and stack them appropriately?  Could we not extract a patch or patch 
> > > set from each of the patch branches to a set of patch files in proper order, 
> > > use them in the spec against a prestine tarball to generate the rpm?  This 
> > > way we get the benefit of both worlds.  If we're pie in the skying, I simply 
> > > don't accept that we have to sacrifice prestine tarball + patches in our 
> > > srpms just to get a way to manage patches against an exploaded source.
> > 
> > Yes, that's certainly a possibility.  It's kind of a medium between the
> > two extremes I proposed.  Building based upon a direct checkout of
> > already patched source means all that you have to do is specify a tag
> > but you lose the tarball + patches.  Exporting patches from the exploded
> > source repo and importing them as files to the package repo is more work
> > but you keep the tarball + patches.  The approach you propose would mean
> > that the package maintainer would need to do some work to specify the
> > set of patches to be extracted and the order to apply them (but wouldn't
> > actually have to do the extraction him/herself), but you keep the
> > tarball+patches approach to building.
> 
> Have anybody thought of using quilt?
> It is a tool that can help _a lot_ in managing patches (especially for
> huge patch sets) .
> I think it could help reach some of the goals here without shifting us
> from using the orig.sourcesa+patches approach, that would be a big
> mistake.
> I've been and I am in the job of tracking changes in multiple trees
> (basically internal forks), it is something you _don't_ want to do
> unless absolutely necessary.
> 
Absolutely.  quilt is the only sane way to manage patches in our current
system.  What I want is to be able to add quilt like commands to a VCS
to be able to manage our patches inside of a VCS.  Having it integrated
gives us access to the things that quilt does well and the things that a
VCS does well.

The important thing in my mind is that both using a VCS as simply a
storage medium for patches and using a VCS as a fork of an upstream
branch leave a lot to be desired.  Combining quilt's patch management
with a VCS's ability to track history and help merge changes across
revisions is what I see as being ideal.

> > The key decision though that needs to be made is whether we take that
> > radical step of abandoning the tarball+patches approach.  My feeling is
> > that it's too radical for right now, but maybe it won't be in the
> > future.
> 
> No it is too radical, full stop.
+1

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070609/05d8611c/attachment.sig>