[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: The Future of Fedora Package Management and the RPM Philosophy

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.

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


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]