Martin Schulze wrote:
Have you thought about keeping these packages out of sarge or did you develop a solution so that users can get their databases updated outside of the stable Debian release?
Hi,what about having an own section for packages like that, next to main, contrib, non-free? There should be a clear policy of what kind of packages can go in there, and what kind of stuff can change during an upgrade. And there should be someone watching over it, like you do with stable point releases, or the security team does with security updates, who would make sure that the upgrades comply with the policy. For example, changes could be limited to rules files, pattern updates etc., but exclude any binaries (don't know how virus engine updates fit into the picture, though). Packages should be architecture-independent to ease testing.
This way, people can choose whether to have this section in their sources.list or not. No other packages should depend on these packages, so that if they break, nothing else is affected. Take a virus scanner, for example: the main binaries, configuration files etc. could live in main; the virus definitions in the extra section.
This mechanism would allow packages with fast moving content to still live within the official debian infrastructure, and the policy would let people know what to expect from packages in this section. This has a clear advantage over maintaining them outside of the official infrastructure, e.g. via backports.org. On the other hand, stable point release policy doesn't need to be softened up to allow fast moving packages in (packages that are moving faster than the point releases anyway).
I don't know the internals of the debian infrastructure very well, so I have no idea how difficult it would be to set up an extra section. But I'm sure people will let me know if it's not realistic :-)
Cheers, Til