Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
Stephen Gran wrote:
> This one time, at band camp, Martin Schulze said:
> > Michael Tautschnig wrote:
> > > In the clamav packaging team we had recurring discussion about how to deal with
> > > clamav in the near (== lenny) and more distant (>= squeeze) future. The current
> > > situation is as follows:
> > >
> > > - We've got severly outdated clamav packages in etch(-security).
> > > - A few packages depend on clamav; those depends are not necessarily versioned.
> > > - Any sensible use of clamav requires the packages from volatile to be able to
> > > handle all features of upstream's current signature database.
> > > - We've had 16 security updates since the release of etch, which constantly
> > > required backporting of upstream's fixes that were included in the volatile
> > > releases.
> > >
> > > We could of course continue this game of telling users that nothing but the
> > > clamav from volatile is what one should use on production systems, but maybe
> > > there are other options as well. Let me see what options we have:
> > >
> > > - Stick with the current scheme. Possible, but neither user- nor
> > > maintainer-friendly.
> > > - Move clamav to volatile only. This would, however, also require that all
> > > depending packages go to volatile, even the depends are unversioned.
> >
> > Does the clamav interface change between versions?
>
> Yes, clamav had several soname changes during the etch release, and
> several configuration and command line options changed. I don't think
> we can depend on it staying stable during lenny.
*sigh*
> > If not, would it be possible that a sufficiently stable version will
> > be included in stable and updates (including new versions) be handled
> > via volatile - including a large note in the clamav package to include
> > volatile.
>
> That's roughly what we're doing now - try to get the most stable
> version we can into the stable release, and track changes via volatile.
> The downside for both users and maintainers is that depending packages
> frequently don't get updated for the changed clamav, leaving them
> performing poorly, or not catching new viruses, or both. The downside
That's the same situation as it is now, right?
Somebody needs to forward port reverse depends that require the old
interface, it seems. However, getting these into volatile should be
easier than getting them into stable (via proposed-updates).
Having all of clamav and all revdeps in volatile would be an
alternative but is probably not an option...
> for us as maintainers is that we have to support a version of clamav in
> stable that no one actually uses. I've done this for 2 releases now,
> and it always feels vaguely pointless by the end of the release cycle.
I can feel your pain.
Regards,
Joey
--
Open source is important from a technical angle. -- Linus Torvalds
Please always Cc to me when replying to me on the lists.
Reply to: