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

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

Stephen Gran <sgran@debian.org> writes:

> Hmm, I rather thought that several people, myself included, had offered
> to take on the work of doing what we thought was valuable, and you have
> been trying to push it off on the security team over strenuous
> objections that it is not their job.

No, you misunderstood my point.  I confess that this is largely
because I was trying to make it in an ineffective manner, so it is my
own fault that it got confused.

What I'm saying is that it doesn't matter yet whose job it is, because
the problem isn't "who does the job" but rather "what job should be
done".  Nor, for the same reasons, does it matter whether we have a
separate archive.  We can figure that out only once we know what the
archive is actually for.

So far, it sounds like the archive is a place to allow certain package
maintainers to make arbitrary possibly destabilizing changes to
packages in stable, without giving any indication about, for example,
that they will backport all changes.

For example, a new set of virus definitions, we are told, may include
a new library and a new strategy for catching viruses.  Makes sense to
me.  But when you add that, are you just going to add in the latest
upstream version of the virus-catcher?  In which case, you are *also*
going to be adding in new substantive features, like say a new
command-line syntax, or a new interface to the mail system, or other
things that are not connected to catching a new category of viruses.

It is *those* changes which are not allowed for security updates, and
should not be allowed for these packages either.

In other words, are your upgrades going to be "install the latest
upstream", or are they going to be "fetch the relevant new things from
upstream and put them in the old thing"?  I agree completely that the
latter is more work, but that is not an excuse for choosing the
destabilizing strategy.

It is for this reason that I was referring to the security team's
procedures early on, not because I care *who* does the work, but
because I care *that* a certain kind of work gets done.  All I heard
was "we want to make arbitrary changes to packages of this kind", and
that is simply not the only way to keep abreast of new virus-catching

Can you write a policy which says that the only changes which will be
made are specific changes known to catch viruses, but *not* the
addition of new features, new interfaces to other parts of the system,
and the like?


Reply to: