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

[Scott Kitterman]

On Wed, 28 Jan 2009 23:00:04 +0100 Alexander Wirt <formorer at formorer.de> 
wrote:
>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.
>

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