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 future. Jeff
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
