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
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
