[Pkg-clamav-devel] The future of clamav wrt. stable/volatile
mt at debian.org
Sat Jan 31 14:54:19 UTC 2009
> Michael Tautschnig wrote:
> > [...] (nice technical insight)
> >> In my opinion all the programs with the ability to talk to clamd (or to
> >> invoke clamscan/clamdscan) can be safely left under stable. The user has
> >> still got the ability to use an updated clamav from volatile with no
> >> problems at all.
> >> On the other hand, programs which can only link libclamav should be
> >> divided into two categories: real-life tools and other tools.
> >> In the the first set are all those things which are designed to scan
> >> live malware, like mail or web scanners. These should preferably go to
> >> volatile.
> >> The second group contains all the rest, which is basically GUIs, offline
> >> file system scanners, and the like. Leaving these under stable is
> >> probably fair enough.
> > There is just a slightly archive-specific problem: A package in main must not
> > depend on something outside main (at least so I guess, I couldn't find the docs
> > stating this rightaway). We'd thus need some clamav package in main, and not
> > only in volatile. Which more or less is the situation we have today.
> > To me, the approach of moving clamav + all its rdepends to volatile really looks
> > like the only option. I thus dared to question all the refusals stated thus far.
> > I'd really like to see some fundamental issues arising by a move to volatile.
> > Still, of course, it means that quite a few packages will need to move to
> > volatile-only.
> A move to volatile-only was not prepared early enough and is a no go at
> the moment from a release point of view as it's not clear what packages
> (or part of packages) would have to become volatile-only, it's unclear
> how this would end up in the release notes AND all this agreed by the
> affected maintainers AND get done within a couple of days from now to
> not disturb the rest of the release preparations
Oh, sure, that at least I was aware of. I hadn't made that clear, sorry. I think
it would already be a benefit of this discussion if we can settle on a strategy
for squeeze. Indeed we still need to satisfy all of the above conditions until
the release of squeeze in that case...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-clamav-devel/attachments/20090131/4a968e65/attachment.pgp
More information about the Pkg-clamav-devel