The Future of Fedora Package Management and the RPM Philosophy

Bojan Smojver bojan at rexursive.com
Sat Jun 9 10:01:44 UTC 2007


Jeffrey C. Ollie <jeff <at> ocjtech.us> writes:

> The primary disadvantage to integrating patch and package management is
> that we move away from RPM's philosophy of using pristine sources.
> Pristine sources have been required because it's possible to easily
> verify that our copy of the sources matches the upstream copy by
> comparing MD5 or GPG signatures. With an integrated repository where
> there are no longer pristine sources, it's not possible to verify that
> our copy of the code matches the upstream copy by comparing signatures
> on tarballs. Verifying the code integrity is possible with the
> integrated repository, but it's potentially much more difficult.

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.

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.

I personally wouldn't like to see Fedora go to such integrated repository.

--
Bojan




More information about the fedora-devel-list mailing list