The Future of Fedora Package Management and the RPM Philosophy
Toshio Kuratomi
a.badger at gmail.com
Sat Jun 9 17:48:23 UTC 2007
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>
More information about the fedora-devel-list
mailing list