Revision 3 as of 2009-05-02 02:56:15

Clear message

This document describes the policy for major updates to Clamav packages in a stable supported distro, including LTS. Micro-release updates are already covered under StableReleaseUpdates/MicroReleaseExceptions. Major updates require a different process because they generally involve interface changes in libclamav and require multiple packages to be tested and updated together to maintain functionality.

Clamav is the premier FOSS anti-virus scanning engine. By its nature, the performance requirements for clamav evolve rapidly as new threats are discovered, so unlike normal packages, stabilizing the version and not changing it does not provide performance stability, it causes performance degradation. Updates to anti-virus signatures are downloaded regularly using freshclam, but often older scanning engines cannot use the signatures and detect newer threats. In order to provide continuing, first class performance and pace the threat, newer versions need to be integrated into existing Ubuntu releases.

QA Process

Packages brought into an existing release must be brought in with a minimal difference from the development/current release (the process should branch from the earliest release to carry the current upstream release which may be the current release and may be the development release). They will go through some functional and integration testing first in the ubuntu-clamav PPA, then exposed to a broader audience in the *-backports repositories, and then finally delivered as updates to all users of each particular release. The process for this is described in MOTU/Clamav/.


This process deviates in a few important respects from standard Ubuntu process and should be approved by the Ubuntu Tech Board.

  • Generally library packages are not approved for backporting. In order to make it reasonable to make an exception to this rule, all packages that use libclamav are tested and backported in tandem (if needed) .

* Generally major version updates are not permitted post-release. Because anti-virus capability degrades over time due to new threats, in the case of clamav not updating only provides an illusion of stability. Updates are essential to maintain an even level of capability.

  • Because the libclamav design is rapidly changing, its rdepends need active maintenance to remain functional. If an upstream is inactive, it may be necessary to drop support for a package in a post-release update. This is unfortunate, but may be unavoidable. In these cases, the dropped package should be used as a transitional package that depends on the most generally suitable alternative so users are not left without an installed, functional package.


This process has been experimentally executed from beginning to end twice. Dapper, Feisty, and Gutsy were updated to Clamav 0.92.2 (which is what Hardy was released with) and Dapper and Hardy are just about to be updated to 0.94.2 (which is what Intrepid was released with). So far, although labor intensive and taking longer to complete than would be ideal, this process has produced good results. When Dapper, Feisty, and Gutsy were updated only two bugs were filed (both Dapper). In one case a user needed to manually adjust a configuration file. In the other case the user had depended on a function provided by python-clamav that had been dropped in the newer release for his own private scanning tool. We were able to quickly package python-pyclamd and provide a suitable alternative.

This process have provided a good balance between cutting edge and stable, integrated capability and seems suitable to extend to Intrepid and Jaunty where clamav is in Main.