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: <3BCC95AA.2050305@ece.gatech.edu>
Date: Tue, 16 Oct 2001 16:16:42 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: cURL packaging progress
References: <6EB31774D39507408D04392F40A10B2BC1FD78 AT FDYEXC202 DOT mgroupnet DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Roth, Kevin P. wrote:


>  1: cURL comes in two flavors -- with and without SSL support.
>     SSL support requires OpenSSL. The choice is made during
>     ./configure (e.g. --with-ssl or --without-ssl). The default
>     seems to be --with-ssl.
> 
>     For cygwin binary tarballs, do we need to make BOTH available,
>     or is it a safe bet that anyone with Cygwin also has OpenSSL?


No.  Take your pick, and indicate in the release announcement that "curl 
requires OpenSSL (openssl-0.9.6-x)".  (or not).  Setup does not (yet) 
have dependency checking, but that is on its way.  Currently, "official" 
packages may depend on other "official" packages -- but not on 
"unofficial" packages (with one exception: postgres depends on cygipc).

Since Corinna has provided an official "openssl" package, you're safe. 
Build with or without ssl; it's up to you -- but make a choice.  don't 
provide both.

 
>  2: If we need to make both flavors available, is there any feature
>     in cygwin-setup.exe that can support installing one or the 
>     other but not both?


Nope. (short of games with version numbers...but I don't want to go there).


>  3: cURL's "standard" for where to place package-specific files
>     is <srcdir>/packages/Cygwin/*. Cygwin's standard seems to
>     be <srcdir>/CYGWIN-PATCHES. Since my goal would be that
>     there AREN'T any cygwin-patches, is it considered acceptable
>     to have a cURL-7.9-src.tar.gz (source tarball) with the 
>     cygwin-specific stuff in an alternate location like this?
>     If so, then you can actually use the main cURL distribution
>     as your cygwin source tarball without making ANY changes to it...


If you're pushing patches into the official source, then send your 
patches to them the way that *they* want (<srcdir>/packages/Cygwin/*). 
The CYGWIN-PATCHES directory is an unofficial standard meant for 
cygwin-required patches and stuff that have NOT yet made it into the 
upstream maintainer's source.

Sometimes this means "moving" stuff from CYGWIN-PATCHES to <wherever> 
when you're dealing with the upstream folks.  It's a pain, but...

for instance, foo-1.0 doesn't build OOB on cygwin.  you patch it, and 
release foo-1.0-1 for cygwin (with stuff in /CYGWIN-PATCHES). Then, in 
your private devel tree, you send the patch to foo/bar.c to the upstream 
folks, and they accept it and release foo-1.1.  (However, there's still 
this special README that you have, but the upstream folks don't.) So, 
you release foo-1.1-1 for cygwin, but it still has 
CYGWIN-PATCHES/foo.README -- and, strangely enough, a patch file that 
merely creates CYGWIN-PATCHES/foo.README).  You then learn that the foo 
people want arch-specific stuff in <stcdir>/packages/<arch>/*, so you 
move foo.README in there, create a <new> patch for the foo people, and 
submit it.  They accept, and release foo-1.2.  Now, foo builds OOB for 
cygwin (and contains all the cygwin-specific documentation you want). 
So, there's no longer any need for CYGWIN-PATCHES in the foo-1.2-1 
package for cygwin. Yay!

(This is where we WANT all the packages to get to, eventually)

Other folks have dealt with 4 and 5...

--Chuck