This is the mail archive of the
mailing list for the Cygwin project.
Re: patches to vendor source trees - discussion
- To: cygwin-apps at cygwin dot com
- Subject: Re: patches to vendor source trees - discussion
- From: Christopher Faylor <cgf at redhat dot com>
- Date: Fri, 2 Nov 2001 21:03:11 -0500
- References: <1004752145.521.38.camel@lifelesswks>
- Reply-To: cygwin-apps at cygwin dot com
On Sat, Nov 03, 2001 at 12:49:04PM +1100, Robert Collins wrote:
>Ok, as promised, here is a new thread.
>What I've written in setup.html is that for a given
>package-version-suffix source tree we supply that pre-patched in
>/usr/src/pacakge-version-suffix/ and also include
>/usr/src/package-version-suffix.patch which is a single patch that when
>applied to the source tree will back it out to pristine, unaltered
>vendor supplied state.
>The goal - of reverting to an unaltered vendor tree - implies that the
>patch _cannot_ be included in that tree. It also implies that the patch
>will include the cygwin specific readme and everything else that is
>eventually included in the binary distribution file.
Couldn't the patch remove itself?
I think that putting the patch outside of the source directory would be
counter-intuitive. I agree that there should be just one file, though.
One problem, of course, is that patch can't reliably remove a file. It
can remove files that become empty but, AFAIK, it can't remove directories
that are made obsolete by the patch.
So, unless we provide a "cygpatch" tool that loses patch for doing the
patching, we're not going to be able to revert the directory to its
pristine state anyway, are we?
Another way of doing things is to squirrel the patches away in a
/usr/src/cygwin/SOURCES directory, like a certain software provider does.
I can't say that I like that method much, though.
How does debian handle this? Is it similar to the method that you