On Mon, Nov 07, 2005 at 12:47:51PM +0000, Robert de Bath said: > On Sun, Nov 06, 2005 at 08:03:26PM +0000, Stephen Gran wrote: > > The existence of the debian security project is predicated on the idea > that some changes MUST be made to keep the system secure. The only > way that this bug fails _that_ test is in that it applies outside the > Linux machine that clamav is running on (ie. I was taking the concept of > 'system' too far). For only that reason I now agree that clamav upgrades > don't fit directly in 'security'. Take note here I am distingushing > between 'stable' and 'security'. But it's nature stable doesn't move > one byte and only changes when a new release is made but 'security' > is a different animal.
OK. > > The volatile project exists to try to bridge the gap for people who > > don't mind a little administrative hassle in order to have the latest > > upstream version of some piece of software. The volatile project aims > > at easy integration with stable, but it is not guaranteed in the same > > way stable is to have an unchanging interface. At some point, things > > will break. > > No that's the aim of a normal backports project, volatile has in it's > aims: > > "but should only contain changes to stable programs that are necessary > to keep them functional;" > > "and they should be confident that nothing is broken by [that] using > 'volatile' as people currently use 'security'" > > Normal backports are for extra features, 'volatile' is so that existing > features continue to work in a hostile world. The problem with volatile is that at some point upstream _will_ break an interface, or an API, or change a config file option. Every effort will be made to work around the changes, and keep it working for users of stable, but the simple fact is that when you change the code base, you introduce new bugs. Something will go wrong, even though we are all trying very hard to make sure it doesn't. I sincerely hope that we can do a high enough quality job that the claims of volatile remain fulfilled. However, given the level of complexity of the task, I am fairly certain that at some point over the life of sarge, some things will go wrong. This is especially true for people using libraries and API's provided by other programs. > > The only possibly appropriate place would be a bug against policy, > > asking that the stable release policy be changed so you can get a newer > > version of an anti-virus scanner. Since most of the things clamav > > detects don't affect linux systems, I have a feeling I can guess the > > answer to that bug report. > > Definitly not. The release policies for a new version of stable have > nothing, directly, to do with this. I realise that most of the changes > that are for a new stable release come from 'security' but even if this > were included in 'security' it doesn't have to be included in the eventual > release of the next 'stable' update. > > Now that I've had a little while to think about the volatile project I > can see the distinction between that and 'security' so I now believe > that this is definitly a Debian website bug. IMO the volatile project > should be given a high level billing close to the 'security' links or > pages. Now who do I send this to ... :-) Unfortunately, for now, volatile is still an unofficial project, and likely to remain unofficial throughout the lifetime of sarge, at the very least. You could ask the people on debian-www (I think that's the list that deals with website issues), or you could file a bug report against the website. At any rate, I am not certain that we are discussing a bug in clamav. How do you fell about closing this bug, and opening a discussion with the website people? Take care, -- -------------------------------------------------------------------------- | Stephen Gran | Gravity brings me down. | | [EMAIL PROTECTED] | | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
signature.asc
Description: Digital signature
