> 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 suits YOU.... 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 BUSINESS NEEDS... > 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... _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
