This one time, at band camp, Noah Meyerhans said: > On Tue, Sep 14, 2004 at 02:10:17PM +0100, Martin Michlmayr wrote: > > Maybe we should just relax the stable update policy for such packages, > > and others which would benefit from regular updates (e.g. drivers). > > I think we do need to come up with a mechanism to allow functionality > updates between stable releases. > > What are we saying to our users by not doing this? Are we saying that > they're better off not using something like an IDS? Can we really not > offer our users the benefit of using packages such as ClamAV, > SpamAssassin, or Snort within the Debian system? I agree - I was planning to offer backports from p.d.o, but this is much better, IMHO - it gets the benefits of Debian's infrastructure, while still being 'out of band' enough that it won't affect users who don't want to be affected. > People have suggested additional sections in the archive for packages > like this... So how 'bout this idea: A new section, possibly entitled > "volatile". Packages in this section declare that they may change, but > only between point releases of the OS. Dependencies of such packages > also belong in volatile. Before a package in volatile can be updated to > a new upstream version, maintainers of packages that depend on this > package must sign off that their package is compatible with the new > version, or they must provide a new package to maintain compatibility. I kind of think the upload is already the 'signing off' (why would you upload something you didn't think would work? - not that it doesn't happen, but you see my point), but I tend to agree here - a higher standard should be enforced. I am not sure how to enforce this without making a lot more work for the RM's, though. > The security team only needs to support the most recent version of the > package in "volatile", since in general they only support packages in > the latest point release of stable anyway. Users who don't install > packages from volatile don't have to worry about running vulnerable > packages due to security holes or outdated databases or whatever, since > they don't have these packages installed to begin with. > > Comments? I just came up with this off the top of my head, making it up > as I went along, so it's very possible that I've overlooked something. I like it. I think making the dependencies go into volatile won't work, however - I am thinking of one of my packages here. clamav-milter uses libmilter - does this put all of sendmail into volatile? Same source package, after all. And at the lower level, of course, there's libc :) Or am I missing something, and you mean 'dependencies' not in the packaging sense, but in the databases used for those programs or something? At any rate, I do like this idea - this is one of my major problems with stable, and towards the end of a release cycle I am usually maintaining something like 40 backported packages for the servers we manage in order to get around this problem. Having a 'volatile' or something would be a huge help to me, at least. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgprjAmyz4WCl.pgp
Description: PGP signature