[clamav-users] [Clamav-devel] ClamAV(R) blog: ClamAV 0.102.0 Release Candidate is now available
themadbeaker at gmail.com
Tue Oct 1 10:29:36 EDT 2019
> I think you misunderstand me, I'm merely stating a fact here.
> Epel won't do anything about libcurl, and redhat won't just backport new
> features "because of". Even so, backport requests take a long time at redhat.
> Maybe the epel guys will include a static version of libcurl for clamav, I hope so.
> I do know that this requirement is for clamonacc, that's just the feature I'm interested in.
> Of course I know how to replace libcurl (I already did it and built clamav myself),
> but clamav packages would need to be done/provided/maintained by a recommended
> third-party (like epel) for the company I'm currently working at (maintaining own
> rpms is fine and I could even do it myself if clamav would provide/maintain a spec-file).
Well, then I guess we could all just sit around waiting another 10
years for an eventual Redhat release that uses a semi-modern version
of libcurl... *rolleyes*
It's a double-edge sword... You can use legacy code for so long, but
then as the OS become more modern, backwards compatibility is only
maintained for so long. Or you can use more modern code, and leave
behind the legacy systems (or at least the systems that choose to use
legacy libraries)... Chicken & the egg... one has to come first before
the other will follow... Sorry you don't get the latest & greatest
features, but that's the trade-off on Enterprise vs Fedora.
As mentioned before, take a look at the EL 6 ClamAV source RPM... It
has zlib building and compiled in statically... You can use that as a
TEMPLATE and build curl statically too, and specify that source when
it builds clamav for your EL 7 system ... Not rocket science...
ClamAV releases are not *that* often... Simply being on the mailing
list is enough to get the announcements when they are released. Often
building a new version is simply replacing the source tar.gz and
firing off rpmbuild...
ClamAV isn't responsible for maintaining spec files, those are
DISTRO-SPECIFIC... Imagine if they were supposed to maintain packages
for every distro out there... That would basically bring development
to a grinding halt...
Grab the last ClamAV .src.rpm for your OS... replace the source
.tar.gz with the version you want, update version number, check if any
.patch files are still relevant or not, and give it the good old
'rpmbuild -ba --clean clamav.spec' and cross your fingers you get a
successful build... It might take a few tries if there are any new
files that have to be added to the files list. That's the great thing
about OPEN SOURCE... If you don't like how someone else is doing
something, you can take that source and modify and build it however it
Depending on how many machines you have, this could be an excuse at
work to start your own local REPO for custom packages tailored to your
> To continue this: it is not only relevant if installing from source, the clamonacc
> binary currently indeed needs the newer libcurl library (so just copying the
> resulting clam binaries to another server would not be sufficient).
Because RHEL (and many other distros) use dynamic libraries... That's
why I said above you could build your own version of curl in with
clamav, leaving the system's version intact...
Sorry if I sound grouchy... Still drinking my coffee this morning...
More information about the clamav-users