The Future of Fedora Package Management and the RPM Philosophy

[Jeffrey C. Ollie]

On Sat, 2007-06-09 at 10:01 +0000, Bojan Smojver wrote:
>
> I think that would be the least of the problems with this approach.
> Because we're building from pristine sources with patches now, every
> maintainer is best off with zero patches to the pristine source. So,
> every maintainer has an incentive to fix the upstream source so that
> the next release comes as close as possible to the spec file created
> by fedora-newrpmspec. The integrated approach would turn package
> maintainers into fork maintainers.

Sure, having a patch-less spec file is the ideal but it's not always
possible.  At the minimum there will always be some packages that have
patches that implement Fedora-specific policy (e.g. changing default
values in configuration files) that would be inappropriate to send
upstream.  There are also many instances where Fedora needs to carry a
patch for a while (e.g. a security patch backported from a newer release
than Fedora ships because the Fedora package can't be updated for some
reason).

So unless package maintainers in some sense are already and will always
be "fork" maintainers - minimizing the number and size of changes from
upstream is an important goal, but it's not the only goal.  What this
discussion has been about is bringing patch development out of a hidden
corner the package maintainer's laptop hard drive and into a centrally
maintained, publicly available version control repository.

> Having one giant integrated repository would make the work of going to a brand
> new upstream version very tedious, as all Fedora specific changes would have to
> be identified and extracted out of the repository first and then reapplied to
> the new tree. With the current approach, the separated patches already exist. If
> they don't apply to the new pristine source, it's either because they are
> incompatible, which the maintainer can fix, or are no longer required and the
> maintainer can drop them. Far less work.

Apparently you have never used a version control system that properly
supports branching and merging.  CVS and Subversion do not count.  Git,
Mercurial, and Bazaar are ones that do and make it easy (in some cases
trivial) to maintain code/patches in branches and then rebase the
patches to new versions of the upstream code as they are released.  With
the proper discipline, keeping track of the changes that we have made to
the pristine code isn't really a problem.

However, I don't want this thread to descend into a debate about the
best revision control system.  We need to be discussing things at a
higher level right now.

Jeff
-------------- 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/afad5817/attachment.sig>