Re: Shipping wcurl in curl tarballs?

[Ryan Carsten Schmidt via curl-library]

> On Feb 9, 2025, at 08:42, Samuel Henrique wrote:
> I would like to understand where you stand on the idea of shipping wcurl
> bundled in the curl release tarball.

I'm not intending to argue strongly for or against this, but here are a few 
thoughts. 

> Ultimately, the goal is to get to a point where users don't need to wonder
> whether wcurl is installed in their machines, if curl is installed, they 
> should
> assume wcurl is also there.

But the user still has to wonder if curl is installed, and know that wcurl is 
now part of curl. To me it makes more sense that if a user wants some software 
(wcurl), they install that software (wcurl), not some other software (wcurl). 

> Distributors of curl can achieve this with a couple of ways, but I'll explain
> why they are not ideal:
> 
> 1) Bundle wcurl in curl at the distribution-level: This is what we do on
> Debian, there's only a curl package and it comes with wcurl. The problem with
> this is that it falls under a gray-area, as one could argue that wcurl should
> be its own package. It also carries the risk of someone forgetting to update
> the bundled copy, as it requires manual action (and remembering it).

I chose not to do this in MacPorts because if you release a new version of 
wcurl on a different schedule than curl, then I have to make everyone rebuild 
or at least reinstall exactly the same version of curl just to get an updated 
wcurl. It also increases the complexity of the Portfile (build script).

> 2) Make the curl package depend on the wcurl package: Not strictly correct as
> the rules for depending on a package are broken, curl does not have a
> dependency on wcurl, strictly speaking. 

This would be backward. wcurl depends on curl, not the other way around. 

> Most distros are choosing to ship wcurl as its own package, but users are 
> still
> left with having to install it themselves, and at that point, they might as
> well stick to wget (if it's installed already).

> If the curl tarball came with a copy of wcurl, distros could easily install
> that as part of the curl package and solve the issue, users would never again
> have to wonder if it's installed or not (like we do on Debian).

It sounds like what you really want is for operating systems to ship both curl 
and wcurl; it has nothing to do with whether wcurl comes with curl or is 
separate. 

I don't know Debian or Linux in general. Maybe it is the case that curl is 
likely or guaranteed to be installed on a fresh OS install. 

In MacPorts, since it is an optional third-party add-on to macOS, nothing is 
installed unless the user asks for it. 

macOS does come with a copy of curl but not wcurl. So I think what you want is 
to ask Apple and other OS vendors to ship wcurl in addition to curl in their 
standard install, rather than ask curl to add this to its distribution. 

> In all these cases, the wcurl repository would still be the place where we 
> make
> changes to wcurl, and wcurl would still have its own releases.

If curl followed your suggestion and bundled the then-current wcurl, and 
distros installed that bundled wcurl, and you later released a new version of 
wcurl, distros would not ship that new version of wcurl until it appeared in 
the next version of curl. Making users wait to receive a new version of wcurl 
seems worse than them being able to get it right away. 
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html