On Sat, 20 Aug 2005, Richard Atterer wrote:

> Hm, I'm not so sure, I'd opt for this whole scheme to be implemented by
> "upstream", not the distro packager.

I can clearly see how most libcurl packagers might want a solution to this
problem. At least application authors of GPL programs that use libcurl should
want it.

> [Incidentally, the above means that libcurl-ssldummy.so should _always_ be
> compiled and installed alongside libcurl, even if neither OpenSSL nor GnuTLS
> is used - I hope this thought is acceptable for you... :-/ An explicit
> configure switch should be necessary for people who really don't need the
> dummy lib.]

I'm open-minded to find a solution that works and that is comfortable to
maintain and to have users use. If that means installing a second lib, I'm not
totally against it. I don't think it matters that much if that is the default
install or not as long as it is a truly good solution.

> Another point in favour of doing this upstream is that otherwise, it just
> won't happen.

That would only show that they (distro people) don't want this fixed badly
enough.

The problem with doing this upstream, in the curl project, is that this isn't
really a work that solves an actual problem for many of us. It solves other
peoples' problems that are related to our lib. Hence this isn't an itch for
most of us, I guess.

If someone wants to fix this for a distro (a libcurl distro for any operating
system) that should work and provide HTTPS functionality for any application,
be it GPL or not, provides a patch or get involved to help us work out these
issues, then I'd be happy and I would assist the work.

I might start the work myself in a not so distant future.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html