Re: Updating scanners and filters in Debian stable (3.1)
On Thu, Oct 07, 2004 at 12:11:32PM -0700, Thomas Bushnell BSG wrote:
> Jesus Climent <firstname.lastname@example.org> writes:
> > Because ssh-from-woody-plus-security-updates is not as useless as
> > spamassassin-from-woody-which-has-changed-so-much-that-is-impossible-to-backport-anything?
> It seems to me that "impossible" is being used in a strange sense
> Part of maintaining a virus scanner may well include backporting
> things, and that may be a fair bit of work to do. There are
> mechanisms within Debian for soliciting help for such tasks, or
> perhaps there is no one willing to do the task.
> But that doesn't mean the task is *impossible*, nor does it mean that
> because we don't have anyone who wants to do it right, we should do it
> wrongly instead.
> The virus-scanner folks seem to insist that keeping abreast of the
> latest virus definitions is very important. I'm inclined to agree.
> But that doesn't mean that stability has become less important, it
> just means that making a good stable virus-scanner package is hard,
> and involves more work than just compiling the latest thing from
> It is certainly not "impossible"; it is at worst merely hard.
More than that, I agree that it is desirable.
Of course, where a trade-off is necessary there will be differences
between circumstances in what is _most_ desirable.
A commitment to doing the hard work of backporting (in this sense),
should not be used as an excuse for not addressing other important
Surely fitness-for-purpose has to be high up the list.
These softwares simply do not, and probably never
will, move at the same speed as the main convoy of stable.
Timeliness is fairly critical to their fitness.
But we could easily have both. Something like:
volatile-bezerker: upstream experimental built against stable
volatile-hotshots: upstream stable built against stable
(please excuse the awful names)
and then parallel to the main archive:
volatile-unstable: upstream backported to stable, intended for volatile stable
volatile-testing: upstream backported to stable, intended for volatile stable
time-served and bug-controlled
volatile-stable: upstream backported to stable, been through volatile RM
Perhaps volatile-stable could feed through into stable-p-u ?
Couldn't upload access to all these come as a package:
You do one, you have to do the other ?
Enforced by the volatile RM ?
Hmm, Perhaps best not to call it volatile ...
Perhaps what I wish for is foolish, or simply not the Debian way?
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com