BUG: clamav packages badly broken
florin at andrei.myip.org
Sat Dec 29 19:34:21 UTC 2007
Kevin Fenzi wrote:
> Are you using amavis packages from dag? or amavisd-new from
> epel/fedora? The two versions are very tied to the clamav version from
> the same repo.
Dag. IIRC, his repo provided clamav, amavisd-new and stuff like that
before Fedora / EPEL, and his packages always worked correctly, so I
haven't even bothered to verify if such packages are available outside
of dag.wieers.com. Until a few days ago, "yum update" failed on el5 due
to a clamav conflict.
To make it clear, I'm not a dag.wieers.com partisan, I just want to use
whatever software works and is easiest to use.
> amavisd-new from fedora/epel should just work out of the box.
> It has the clamd start script in it due to the way the clamav package
> in fedora is setup.
> These have been in fedora for ages...
Oh great, that rot has been lingering there for ages and now other
packages must work around the bug in the clamav packages. :-(
> So, let me recap what I know and perhaps someone will think of a
> brilliant solution:
> - The fedora clamav maintainer wants to do things the way the package
> is currently setup. They don't want to change it to be more simple/easy
> to understand, or fix it to be more usable. This package meets all the
> package guidelines.
> - I attempted to setup a clamav for epel that was based on the dag
> rpms. However, amavisd-new, klamav, and other packages in fedora (and
> thus epel) depend on clamav being packaged in the way that it is. This
It's not that other packages have just to work around the broken clamav
packages, but they need to make the assumption that the bug is there in
order to be able to use clamav.
> would mean all those other packages would have to rework their specs
> for the clamav package.
> - The amavisd-new maintainer in fedora/epel reluctantly agreed to
> maintain the fedora version in EPEL.
> So, I don't see much way out... we go with the version currently in
> fedora/epel, unless someone can talk the maintainer (and the
> maintainers of all the dependent packages) into changing the package.
> Any other ideas?
Back to using Dag's repo - setup all sorts of yum exceptions, so that
the broken EPEL packages do not interfere with the good packages
provided by Dag. Welcome to the repo hell. :-(
More information about the epel-devel-list