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: Samuel Henrique via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 9 Feb 2025 19:50:19 +0000
On Sun, 9 Feb 2025 at 19:02, Ryan Carsten Schmidt <curl_at_ryandesign.com> 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,
Date: Sun, 9 Feb 2025 19:50:19 +0000
On Sun, 9 Feb 2025 at 19:02, Ryan Carsten Schmidt <curl_at_ryandesign.com> 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.htmlReceived on 2025-02-09