Re: The future of clamav wrt. stable/volatile
On 2009-01-25, Michael Tautschnig m...@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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The future of clamav wrt. stable/volatile
Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009: On 2009-01-25, Michael Tautschnig m...@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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The future of clamav wrt. stable/volatile
Michael Tautschnig wrote: 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. Does the clamav interface change between versions? If not, would it be possible that a sufficiently stable version will be included in stable and updates (including new versions) be handled via volatile - including a large note in the clamav package to include volatile. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
