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

[Alexander Wirt]

Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009:

> 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.
Ehm, its not a solution for me to move dansguardian to volatile only. It
guess that counts for other applications that link against clamav too.

Alex