> 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... Best, Michael
Attachment:
pgpLwGNIp9JkN.pgp
Description: PGP signature