On Tue, 08 Feb 2000, Peter Eisentraut wrote:
> On Tue, 8 Feb 2000, Chris wrote:
>
> > How do I make a patch that includes new files?
> Here is something that was recommended to me by Jan, and it seems a number
> of other people follow a similar road.
[snip]
> When you're done you create a patch between pgsql.orig and pgsql.work
> using diff -c -r whatnot and send that in. Then you do cvs update again an
> the game begins anew. This also has the advantage that if someone mangles
> your patch slightly (such as running indent on it) you won't get funny
> merge conflicts when you cvs update over your self-patched cvs tree.
This is also SOP for patching for RPM building. The RPM philosophy is to
always build from pristine released sources -- if changes are required in order
to shoehorn the package into the RedHat FHS confines, then those changes are
distributed as a set of patches against the pristine sources. The build
process then applies those patches at build time. The idea is to allow RPM
users to easily rebuild packages by simply pulling off the latest pristine
tarball, then, after editing the patches appropriately, a simple 'rpm -ba'
command completely rebuilds the packages, which you can then install.
For the RPM's, I have a pristine tree in postgresql-x.x.x.orig, and the work
tree in postgresql-x.x.x, then issue a 'diff -uNr ' between the two trees.
Then, I rename the work tree to postgresql-x.x.x.patched, then issue the 'rpm
-ba' (or variants, depending on how far I want the build to proceed), which
applies those patches to a new pristine build tree.
I have found that the patchset for PostgreSQL doesn't usually vary much --
until now, as there's a whole new regression test suite, and the majority of
the RPM-ifying patches were in the regression suite (so that it could be
prebuilt and run without using make, and without having a source tree around at
run time).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
