This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patches to vendor source trees - discussion


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@MarathonOil.com>
To: <cygwin-apps@cygwin.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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]