The Future of Fedora Package Management and the RPM Philosophy

[Simo Sorce]

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:
> > On Friday 08 June 2007 15:00:17 Jeffrey C. Ollie wrote:
> > > If we want to be more radical, we could integrate the package and the
> > > patch repositories. Package building would no longer use pristine
> > > sources and patches to produce a binary package. Instead, the build
> > > system would pull already-patched code out of the repository and build
> > > the binary package from there.
> > 
> > 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.

> 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.
Keeping a parallel tree is by all means keeping a fork, make it easy to
screw up and very difficult to do merges, what will happen is that
packages will lag behind more and more, and syncing up with upstream
will become more and more difficult. Please don't even think of doing
something like that for maintaining packages.

Simo.