The Future of Fedora Package Management and the RPM Philosophy

[Toshio Kuratomi]

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
-------------- 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/20070608/7bb151ce/attachment.sig>