[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Pkg-clamav-devel] [SRM] clamav 0.94.x EOL


On Sat, 10 Oct 2009 01:39:41 am Philipp Kern wrote:
> On Thu, Oct 08, 2009 at 08:31:49AM -0400, Scott Kitterman wrote:
> > I do not think removal is the approach that would be best for users.  It
> > would leave them with an orhpaned, non-working package and they will have
> > to upgrade systems to a newer release, install from external sources
> > (e.g. volatile), or compile from dource directly.
> >
> > Updating clamav and needed rdepends to something that upstream supports
> > would be more benificial for users.  With a half a year of notice, I
> > think this is managable.
> >
> > This is the approach Ubuntu will be taking (they already have a full set
> > of updates in their backport repository that is tested and almost ready).
> Especially as there is no use in keeping old versions of a virus scanner
> around which cannot be updated anymore and as a sufficient amount of people
>  do want a virus scanner on their box.
> I ask me, though, how many people are actually using the version Lenny
> provides.  If they do, they probably do not know it better to use volatile,
> or do not trust it because it's not as official as the stable suite is.
> Of course we could do a noisy drop of clamav out of Lenny and point people
>  to volatile, I just wonder if that's actually a disservice to our users.
> For squeeze I see two proposals:
>  a) Either we could relax the policy for clamav a bit if sufficient upgrade
>     testing is ensured (like Ubuntu already does, thanks to Scott's work)
>  or
>  b) We push volatile to be a really official service alongside the stable
>     tree residing on our normal infrastructure as a goal for squeeze.
>     Volatile updates are currently undergoing testing (thanks to the clamav
>     team) but maybe a coordinated effort in reviewing for stable
>  suitability of the Ubuntu and Debian counterparts of clamav maintainance
>  would help us to convince a possible set of people not using volatile yet.
I'd like to vote for b) and in such a case the security team is willing to 
provide full security support for the packages in volatile (which was already 
agreed upon during the security team's meeting in Germany).


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: