[Pkg-clamav-devel] The future of clamav wrt. stable/volatile

[Moritz Muehlenhoff]

On 2009-01-25, Michael Tautschnig <mt at debian.org> wrote:
>
> --===============6401238421216507687==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6"
> Content-Disposition: inline
>
>
> --UfEAyuTBtIjiZzX6
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Dear Release Team,
>
> In the clamav packaging team we had recurring discussion about how to deal with
> clamav in the near (== lenny) and more distant (>= squeeze) future. The current
> situation is as follows:
>
> - We've got severly outdated clamav packages in etch(-security).
> - A few packages depend on clamav; those depends are not necessarily versioned.
> - Any sensible use of clamav requires the packages from volatile to be able to
>   handle all features of upstream's current signature database.
> - We've had 16 security updates since the release of etch, which constantly
>   required backporting of upstream's fixes that were included in the volatile
>   releases.
>
> We could of course continue this game of telling users that nothing but the
> clamav from volatile is what one should use on production systems, but maybe
> there are other options as well. Let me see what options we have:
>
> - Stick with the current scheme. Possible, but neither user- nor
>   maintainer-friendly.
> - Move clamav to volatile only. This would, however, also require that all
>   depending packages go to volatile, even the depends are unversioned.
> - Do fairly large updates (i.e., possibly new major versions) through
>   stable-proposed-updates.
> - ???
>
> We don't necessarily seek a solution for lenny, but would like to start a
> discussion and receive some comments from people involved in release management
> to see which further options we have, or which of the proposed are acceptable.

We had discussed this during the Security Team meeting in Essen: We believe
clamav shouldn't be included in stable; malware scan engines are a constantly
moving target and it's pointless to backport changes since new signatures
constantly require new scan engine features all the time. So moving it to
volatile is the best solution for everyone.

Cheers,
        Moritz