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

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


I admin a small system with mailscanner, spamassassin, clamav, etc.
I would dearly like to move the system as a whole to a debian sarge base,
and will likely do so, regardless of the outcome of this debate/process.

The outcome _will_ impact how I admin it in future.

On Thu, Oct 07, 2004 at 02:07:18AM -0400, Stephen Gran wrote:
> This one time, at band camp, Thomas Bushnell BSG said:
> > 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?
> I am terrible at doing things like drafting policy statements, but I
> will take a stab at it.

I've never drafted a policy statement, but hey ...

Here is my counter proposal:


Software is best when it is:

Just works

For different software, different people, different uses, etc.
some values may be more important than others.
And, sometimes you have to choose.

There is a category of software whose utility is very sensisitive to 
and derives from, in a very great part from it's timeliness, how up-to-date.
People have variously called this software ephemeral, volatile, perishable
to denote this quality. mailscanner, spamassassin, clamav, etc. are in this

We consider here the 'volatile' software that is security software.


To support this category of software on stable. (on, not in).


When I _need_ (not want, _need_) the latest upgrade, I need it now!  Not in
two days time when someones futzed about with it (and like as not broken it).
Otherwise I can just build it myself - I do now anyway!

I'd rather not pin up to sid.  Packages in sid seem to be built against sid.
I'd end up with unstable libc upgrades and all sorts (not that I've ever had
a problem with a libc upgrade from sid). Testing is just too late.
[please correct me if I'm wrong about this, and I'll just go away and die
quietly of embarassment somewhere]

The main distribution should be more than just 'stable' it should be 'best'.

Debian can do better.  Here's how.


There is a 'list of packages' for the archive.  Packages going onto the list
must satisfy the criteria:

	utility is very sensisitive to and derives from, 
	in a very great part, it's timeliness - how up-to-date it is.


	is security software
packages should be 'built as backports' in the sense:

	built with and against stable, as far as possible.

	ideally, built from the same source as experimental/sid/etc.
	with the minimum of fuss, and quickly.

	dragging whatever dependencies they require/prefer 
	into the volatile archive with them.

Clearly for packages with their roots in unstable there need to be ways 
	for admins and maintainers to exchange and track information

	to indicate clearly to the less experienced the status 
	and potential risks associated with available options.

The Debian Project has a full array of systems to do this.
But I shall offer two suggestions:

	Perhaps volatile should have its own parallel stable/testing/unstable?
	Might I propose that an unstable section be named after sid's sister, 

	Bug reports are useful. On short timescales positive reports, in a
	machine readable format (think apt-list-bugs, etc), could be just 
	as much so or more so.  
	Could the BTS handle somehting like this ?

I haven't covered the issue of API/ABI changes.  I'm kinda hoping that proper
dependency tracking can handle this.

Similarly I realise that there is a hazard to the purpose of running on 
stable attached to dragging arbitrary dependencies into the archive,
But this seems like the best limitation strategy to me.  Perhaps there
will need to be more flexiblity around this (trading off more time spent
packaging to get less drag-in effect).


* its fast

	thats the point. fast. fast makes timely.

* better throughput

	otherwise there _will_ be multiple admins doing this themselves 
	around the world.

* better distribution of labour

	With the best will in the world, the best man for the job cannot 
	always be available.  If the primary admin is not available to 
	make deployment decisions, and deal with builds, the next in line 
	cannot be expected to always achieve the same level of performance.  
	With an internet wide team of experts, we can do better than that, 
	even the primary admin can perform better.

* proper support

	IMHO, if mailscanner, spamassassin, clamav, etc. cannot be supported in 
	something like this way, and the status quo continues, where programs in
	'stable' languish in a woefully unsupported state, then I fail to see
	the value in shipping them in sarge.

	For this category of software, QA needs to happen more in the loop
	after the package is built, and less so before. 

* superior firepower

	For so many things, Debian is the best.
	This is a significant niche.
	Debian can be the best at this.

For me, this is a important issue for debian.

In the words of Jack Nicholson (in "Mars Attacks", I think):

	"Together we are stronger"


I can't do s/volatile/as-yet-to-be-named/g,but please read it that way if
you wish.

I've put in "have a security application", because

	This is what I care about.

	This is what we are talking about.

	I believe a narrow focus could be good for getting such an effort
	off the ground.  Otherwise this is just (approximately) a charter
	for bringing backports.d.o into debian proper.

I hope my proposal is clear.  I believe this proposal is very much at odds
with the model based on security.d.o that is being advanced, and I hope
the reason is clear: timeliness, its the whole point.  As always, if you 
have questions, corrections, see dificulties, have a better idea, just
plain disagree, or whatever, I'd like to know.

Incidentally, I can't help feeling a little dragged down by the tone
of some of the words we're using.  'Fresh', 'timely', 'up-to-date' as 
well as a host of more abstract words like 'useful' and 'appropriate', 
describe the kind of software we're talking about.  I realise that
'destabilise' is the term that is use to describe a very legitimate
concern, but I wish to point out that 

	The quality of upstream support for software in this 
	category is often _exceedingly_ high.  

So much so, that I feel there must be a corresponding legitimate concern 
that any backporting-of-the-security.d.o-type not only risks unnecessary 
delays, but risks the quality of the outcome.

And, yes, I'll still be here mucking in with the day to day when it gets 
going, whatever the outcome.  If we have a system I can use, I can do more
that is (I hope) of use to others.



Reply to: