On Wed, 28 Jan 2009 23:00:04 +0100 Alexander Wirt <[email protected]> wrote: >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. >
I maintain klamav. As I understand it, DM's don't have upload rights to volatile. I don't really have time to deal with sponsorship hassles currently, so I'd probably orphan the package. Scott K -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
