Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3D02D765.8010202@ece.gatech.edu>
Date: Sun, 09 Jun 2002 00:19:49 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Billinghurst, David (CRTS)" <David DOT Billinghurst AT riotinto DOT com>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: package offering: gnupg
References: <FAC87D7C874EAB46A847604DA4FD5A642075E2 AT crtsmail DOT corp DOT riotinto DOT org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Billinghurst, David (CRTS) wrote:

> I'd prefer the re-autotool stuff to be part of the user build process.
> I was going to propose this for ImageMagick, as it reduces the patches
> from approx 1 Mb down to 2 lines.  Much easier to understand.


IMO, this is a maintainer decision.  If David wants to keep the cygwin 
"fork" small, but require the autotools to build-from-source, that's up 
to him.  Some existing packages do it that way; others include a 
massively huge "re-autotool" patch in the -src package.  Either way.

Ideally, David's method is "better" -- because that way it's easier to 
"up-port" the cygwin fork to a new version, it's clear what the 
"important" changes are that need to be pushed upstream, etc.  However, 
it's harder for the cygwin maintainer to keep things separate -- 
especially the "./foo-VER-REL.sh spkg" step, because the mkpatch 
sub-step becomes tricky if not impossible to automate...therefore, you 
have to manually maintain the (small) patch.

I tend to use David's method when I'm syncing against source in a CVS 
repository (libtool, a few others).  I tend to just say "ah, the heck 
with it" and ship a mega-patch in other cases.

FWIW, I haven't had a chance to look specifically at David's gnupg 
package yet.  I'll try to do so tomorrow -- but I'm on dailup now... :-(

--Chuck