Mail Archives: cygwin-apps/2001/10/16/16:20:01
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
- Raw text -