On Sun, 5 Oct 2003, codemastr wrote:

> > I was going to keep it separate, in a manner similar to how we use
> > OpenSSL.

> Right, but to me ares is kind of different. OpenSSL, and zlib for that
> matter, are kind of "standard" libraries (especially in the case of zlib).
> Most *nix systems either come with it by default, as a recommended package,
> or are generally installed by just about every admin. On the other hand,
> ares is generally not installed by default. And, even if it does happen to
> be installed on the system, it's going to require the user to install the
> patched version anyway.

Not everyone will need to apply any patches to it. But yes, I agree with your
general description. It is not what I consider a "standard" library.

> If you decide not to add it to the CVS, I think the next best thing would be
> to maintain an ares-1.1.1+curl.tar.gz so that way at least the docs can
> simply say "get the ares version from curl.sf.net/...." rather than
> requiring the user to install 50 different patches.

My intention so far has been to provide one single patch for ares 1.1.1 that
fixes all the known issues. Your point is still valid though.

> I'm sure, eventually, someone is going to get IPv6 support working in ares
> (I've tried myself a few times but failed miserably), so that will be
> another patch people have to install.

I haven't even been close to attempt anything in that area yet...

> It just seems like a good idea to try and make installing ares as painless
> as possible.

I've given this some more thoughts now, and I think I'll proceed like this:

- I'll add the 'ares' subdirectory and all the associated files to the curl
  CVS repository. This way, we can keep track of all the changes etc.

- I'll maintain an ares-specific changelog for the changes we do to it.

- I'll produce a separate ares-curl package, that is totally independent from
  curl. Basicly the original ares 1.1.1 with all the changes we have gathered
  that the ares maintainer ignores (massively increased portability). The
  package will be fine to build and use with libcurl.

- Thus, the standard curl release source archive remains ares-less.

Good enough?

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf