On Fri, 2007-06-08 at 14:00 -0500, Jeffrey C. Ollie wrote: > The question is, do we want to move away from RPM's philosophy of using > pristine sources plus patches to build binary packages? Determining the > answer to this question is a fundamental first step before decide > “what's next.” > I want to stay with the pristine sources philosophy. It's one of the guiding principles of rpm that I have always appreciated. If people are against it, I'll express some more logical arguments in favor of them. As for patches... SRPMs should definitely ship with multiple patches to that pristine source as we do now. How we store and/or generate the patches in our repositories before going to the build system is what I would like to see change. [snip a lot of good analysis] > There are (at least) two different approaches that we could take to > managing patches in a central, public manner. One method would keep the > traditional package repositories and add separate patch management > repositories. This method would preserve the pristine source plus > patches philosophy of RPM. Another more radical approach would be to > integrate the package and patch management repositories into one. [snip details of the two models] The model I envision is a mixture of both of the above. It preserves pristine sources and multiple patches while doing the work inside of the SCM and the spec file. A single repository holds the spec file and the "patch management branch" (which is a branch of the vendor branch). Creating patches is done by working on separate branches inside the "patch management branch". When issuing make build, make mockbuild, make x86_64, etc patches listed in the spec file could be automatically generated from the patch management branch and the pristine tarballs either downloaded from a lookaside cache or extracted from the vendor branch. > Another disadvantage of integrated management is that unless the package > maintainer disciplines himself/herself it can become difficult to > separate changes to the code that were done to implement Fedora-specific > policies (changing defaults in configuration files, moving files around > to suit the FHS, etc.) from changes that were done to fix bugs or > security problems (and thus might be of interest to upstream > developers). Guidelines on how to manage vendor, patch, and policy > branches will help maintain that discipline (but vigilance will be > necessary). > I disagree with the assumption that this will be harder in an exploded tree. Right now I need to manually keep all my patches separate (having a vanilla tree and separate feature trees, using gendiff, or using quilt [of which the latter is the only one that scales]). With a VCS each changeset can exist in its own branch and the VCS will provide facilities to separate the changes, merge conflicts, etc. Currently there is a temptation to put separate features/bugfixes into one patch because it is hard to manage the overlap between patches. With a VCS, there are tools to help you manage that. -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
