Re: Shipping wcurl in curl tarballs?

On Sun, 9 Feb 2025 at 19:02, Ryan Carsten Schmidt <[email protected]> wrote:
> > On Feb 9, 2025, at 08:42, Samuel Henrique wrote:
> > 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.

But curl is literally installed everywhere, one has to wonder, instead, whether
curl is NOT installed :) [0]

"and know that wcurl is now part of curl": Yes, but if we get to a point where
most curl distributors ensure wcurl is present if curl is there too, then "not
having wcurl" becomes the edge case.

> To me it makes more sense that if a user wants some software (wcurl), they
> install that software (wcurl), not some other software (wcurl).

This would still be possible, the distributor can choose to have different
packages if they want. They can also create a virtual package "wcurl" that
installs curl, if they want to do both things (bundle wcurl in curl and keep a
separate wcurl package).

> > 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).

"It also increases the complexity of the Portfile (build script)": exactly,
this would be gone if wcurl was already present in curl's tarballs (granted you
would want to ship both together). You would still have the choice to not do
it.

> 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.

No, we already have this today, pretty much all distros ship wcurl [1], and the
ones that are not on that list just didn't have time to pick up from their
upstream distros (e.g.: CentOS will pick up from Fedora).

> 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.

I'm not concerned with that, wcurl release cadence is slower than curl and I
don't expect wcurl to get any big changes from now on. I doubt users will
notice the delay of 2 months that it could take in the worst case.

Since December 2024, there's only a single small change that might be upcoming
in a new release[2], we have nothing else planned.

[0] Sorry about the joke, but it holds the point.
[1] https://repology.org/project/wcurl/versions
[2] https://github.com/curl/wcurl/issues/42

Cheers,

--
Samuel Henrique <samueloph>
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html