Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009: > On 2009-01-25, Michael Tautschnig <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
