cURL packaging progress

Charles Wilson
Tue Oct 16 13:16:00 GMT 2001

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...


More information about the Cygwin-apps mailing list