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
Message-ID: <06f201c16e2d$01f8c9b0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>, <cygwin-apps AT cygwin DOT com>
References: <6EB31774D39507408D04392F40A10B2BC1FDFC AT FDYEXC202 DOT mgroupnet DOT com>
Subject: Re: patches to vendor source trees - discussion
Date: Fri, 16 Nov 2001 10:26:51 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 15 Nov 2001 23:25:01.0461 (UTC) FILETIME=[BF905C50:01C16E2C]

Thank you...

At the moment setup.exe only looks for a single -src tarball. But, I've
already indicated that I'd like the patch and src tarball separated
longterm (http://sources.redhat.com/ml/cygwin-apps/2001-11/msg00303.html
last paragraph). So we agree there. However that doesn't discriminate
between Chucks layout and mine (just put Chucks other files  in a small
tarball of their own that gets versioned and the same benefits can be
gained).

As for having versioned source trees, I think that that is up to the
user. Why? Because rm -rf is a wonderful way to start clean, and I think
the pristine source tarball should be left intact in the location it's
downloaded to. So versioning the source tree when the patchs/scripts etc
are versioned is of little value.

On the automated side, I think _everyone_ would like automation, but
what we need is for that automation to be created/adapted from
elsewhere.

I don't like the idea of having to download the binary distro to find
the readme in the source distro. If I want the source, why would I waste
time+bytes on the binary distro.

Rob

===
----- Original Message -----
From: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>
To: <cygwin-apps AT cygwin DOT com>
Sent: Friday, November 16, 2001 1:52 AM
Subject: RE: patches to vendor source trees - discussion


My 2-bits, for what it's worth...


I like the idea of having one pristine source tarball, plus a
PKG-VER-REL specific patch file(s). For downloading. This means changes
from one release to the next don't require downloading another large-ish
source tarball, but simply a (hopefully) smaller patch file.

Once downloaded, I think the process (whether automated or
human-driven-but-well-documented) should end up creating a PKG-VER-REL
directory for the patched source. This makes it easy to hack at it,
build it (either in a sub-dir or separately), and still start fresh when
the next Cygwin-REL patch is downloaded.

Regarding automated vs human-driven, I'd vote for as fully automated as
possible. But the people that are interested in grabbing source and
hacking at it should be capable of following directions also, as long as
they are easy to find.

Regarding where in the source package to keep a .README file, I think it
should be up to each package maintainer. There should be a "standard"
suggestion, in case they don't already have something else in place
(e.g. CYGWIN-PATCHES). However, for those upstream sources that already
have a place to keep system-specific files (in my case,
curl-7.9.1-1/packages/Win32/cygwin) that should be the right place. The
best way to FIND this .README file would be to look in the binary distro
for usr/doc/Cygwin/pkg-ver-rel.README, which should document the
non-standard place where the master copy is located...


--Kevin