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