On Sun, 9 Feb 2025 at 19:02, Ryan Carsten Schmidt <c...@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.html
