Hello, how I can to update cURL from 7.61 to 7.81?
By choosing a different distro? Rocky derives from RHEL 8 and Red Hat maintains versions of their choosing in RHEL. What RHEL has, Rocky has.
However, Red Hat does backport both both fixes and some features to the versions they do maintain. Therefore, the curl is not necessarily the “7.61” that the upstream curl was when Red Hat did pick it for RHEL 8.
Furthermore, Red Hat does occasionally rebase some packages. Whether that will happen to curl is up to them.
By way of experimentation I just downloaded the curl 7.81 source code archive from curl.se and compiled it on Rocky with no immediately apparent issues.
So about one minute after deciding to try this out, what I have in the build directory right now says:
src/curl --version
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 zlib/1.2.11
Release-Date: 2022-01-05
Protocols: dict file ftp gopher http imap mqtt pop3 rtsp smtp telnet tftp
Features: alt-svc AsynchDNS IPv6 Largefile libz UnixSockets
If all you need is a 7.81 curl binary, that’s all it takes to get one for yourself. Whether that’s actually what you want and whether it’s sufficient for your use case depends on what you intend to do with it, of course.
The problem with this, is that it won’t get security patches applied automatically.
Yep, unfortunately that will be a choice that they need to decide for themselves. Stay with the packages that are available in Rocky by default, or if they want the latest and greatest means they would need to compile and maintain it themselves. Either that or wait and see if a later version will appear in RHEL/Rocky or from epel/elrepo repositories, or even wait for Rocky 9 which would have much more chance of resolving the problem!
Or as @jlehtone says, choose a distribution based on your requirements of needing the latest and greatest packages - in which case a stable distribution like Rocky, just like RHEL and other stable distros like Debian - are not for you.
EPEL policy is to not offer what RHEL already has, isn’t it? ELRepo focuses on drivers.
Some other third-party repositories are more willing to replace base packages, but how diligently?
CentOS Stream 9 has currently curl-7.76.1-14.el9. Even if RHEL 9 would get the curl 7.81 the problem would remain: the stable distribution will not have the cutting edge of curl, whatever its version will by that time.
That is a good point. If you need to run a specific version, you can have it in separate location that you explicitly enable for current shell session. That way other programs from other packages (that you will not run in that session) will still see only the system’s version. That is what HPC clusters often do, usually with the help of environment-modules package.
Yep, was just giving examples of trusted repos that people add. Obviously you need to be careful about adding unknown ones that haven’t been verified as safe like epel, elrepo, rpmforge, remi, etc.
1 Like
Well said.
There are levels even in “safe”. EPEL is definitely safe as in “does not conflict with base repos”, how quickly various packages in it get rebuilds is less strict. For example, EPEL had sources ready to (re)build for 8.5 before Rocky did, but did all EPEL maintainers dash to work like Rocky devs did? I bet not.
Ennio Morricone wrote a song “A gringo like me” in 1963. Its chorus lyrics contain:
There’s just one kind of man that you can trust
That’s a dead man
Hi FrankCox ,
Could you please share the compiled version of curl 7.81 with rocky .
we have some http framing issues of curl so wanted to try with higher version of curl.
Thanks,
Shilpa
You can download new curl rpm packages at rpmfind.
For example here are download links for x86_64:
7.81 : http://rpmfind.net/linux/openmandriva/4.3/repository/x86_64/main/release/curl-7.81.0-1-omv4050.x86_64.rpm
7.84 : http://rpmfind.net/linux/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/c/curl-7.84.0-1.fc37.x86_64.rpm
I would not recommend using RPM’s from OpenMandriva in Rocky. Fedora also isn’t ideal either, since the dependencies that it could rely on will not be in the repositories that RHEL/Rocky has.
It would be pretty stupid to do that. And I most definitely wouldn’t recommend it. It would be better to just compile your own, natively on Rocky.