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

Re: Updating scanners and filters in Debian stable (3.1)



On Mon, Oct 11, 2004 at 04:30:36PM -0400, Stephen Gran wrote:
> This one time, at band camp, paddy said:
> > On Mon, Sep 13, 2004 at 12:45:34PM -0400, Stephen Gran wrote:
> > > This one time, at band camp, Martin Schulze said:
> > > > A while ago there was a discussion in which it was said that such
> > > > tools are rather useless (or even dangerous) if they don't get their
> > > > database updated in accordance with new viruses/security problems.
> > > > 
> > > > Some of these systems are hence not suitable for a stable Debian
> > > > release where updates will only be made for security problems and
> > > > very important bugfixes.
> > > > 
> > > > Have you thought about keeping these packages out of sarge or did you
> > > > develop a solution so that users can get their databases updated
> > > > outside of the stable Debian release?
> > > 
> > > ClamAV uses freshclam for virus definitions, so the actual database
> > > updates are covered.  That being said, there are relatively frequent
> > > changes to the scanning engine as well, leaving me feeling like it may
> > > not be the best choice for a stable release.  I do plan to continue
> > > offering out of band up dates on p.d.o, but I am not sure this is the
> > > best way to proceed.  Feedback welcome,
> > 
> > Stephen,
> > 
> > Revisiting your original question.
> > 
> > Reading the Debian Policy Manual as I am right now:
> > 
> > 	2.2.1 The main section
> > 	...
> > 	packages in main ...
> > 	must not be so buggy that we refuse to support them
> > 
> > While you clearly do not refuse, it was argued that the net effect is 
> > likely to be just so.
> 
> People seem to comparing apples and oranges rather frequently in this
> discussion, so I will try to be very clear here.  I am not talking about
> regular bugs in clam that affect the security, stability, or packaging
> of the software itself.  Infrastructure is already in place for those
> sorts of problems.  

You're right of course, I have been confused by conversations about other
packages.  Given that a package lives up to what is expected of packages
in stable (or can reasonably be expected to do so), is it not 'supported'
by definition?  

It would seem a little presumptious to consider the converse: that packages
needing it should maintain a presence in volatile, as a condition of
fullfilling their obligations to stable.

Either way, this does underline the potential value of volatile, 
as you go on to point out.
 
> The problem is only that packages of this sort need to change to keep 
> up with the threats they are designed to combat.  The inability to pick 
> up a new virus is not a bug in the same category as 'segfaults at start'
> or 'never worked at all' - it is a 'this used to work, but times have 
> changed' bug, similar to a 'please package new upstream version because
> it has more features' kind of bug.  If clam releases in stable, and
> there is no volatile, then there is no in-band mechanism to deal with
> these sorts of bugs.  So there will likely be tons of 'does not catch
> virus X' bugs tagged wontfix and people will just be referred to out of
> band update sites.  This is not the end of the world, but I think we can
> do better.

Agreed.

> > Perhaps the question now should be:  does volatile modify this?
> > 
> > (for example, does volatile count as support for this purpose).

I realise now that this is perilously close to 'an excuse for not 
living up to the standards of stable', which I did not intend.

> I don;t think it relates to that part of the policy manual, as I said
> above, but perhaps some people feel so.

Just reading that paragraph in the policy manual, there seems an ambiguity 
in 'support', but I am not familiar with whole document and its interpretation, so I am likely just misquoting.  I really was reading that at the time and my 
post finger got itchy (again :)  And I thought that data point might assist
you in addressing one of your original questions.

I have no strong feeling either way, beyond that volatile seems a strong
positive move to do worthwhile work.

But if 'support' for stable is defined to ignore the 'useless' question,
then it seems volatile will define 'support' to a different standard.

Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall



Reply to: