Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Shipping wcurl in curl tarballs?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ryan Carsten Schmidt via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 9 Feb 2025 12:55:13 -0600
> 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.
Date: Sun, 9 Feb 2025 12:55:13 -0600
> 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.htmlReceived on 2025-02-09