Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Subject: patches to vendor source trees - discussion
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: cygwin-apps AT cygwin DOT com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.15 (Preview Release)
Date: 03 Nov 2001 12:49:04 +1100
Message-Id: <1004752145.521.38.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 03 Nov 2001 01:53:23.0028 (UTC) FILETIME=[51F0F140:01C1640A]

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.

The current practiced method is to include a directory with 1 or more
patches that have been applied to the source tree.

I don't like this for 2 reasons.
1) applying and twiddling multiple patches can get into ordering issues.
2) For an end user who simply wants to build the package with different
configure options, or who wants to upgrade to an as-yet unreleased via
cygwin setup vendor source tree version, multiple patches will make the
task harder, not easier - unless we have a kernel-patch style script
that can automate that. And I think that kiss applies to the idea of a
script for this.

Now, an additional benefit of mandating a single patch in the level
above is that it's _easy_ for new maintainers. That's got to be a good
thing.

Also note, it is possible to do both: to include a set of patchs in a
directory in the source tree that have been applied individually to the
source tree... and have a global patch that will clean the whole tree
back to vendor status. Likewise reversing that patch and applying to new
vendor tree will create those separate patches, AND attempt to have them
applied straight into the tree.

I've no objection to doing both, other than we should not make having
both a _requirement_. 

Rob