Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
This one time, at band camp, Michael Tautschnig said: 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. A way around this problem might be to integrate volatile slightly more with the main dak archive. Treating volatile (from the point of view of dak) as a kind of proposed-updates queue (that may or may not get rolled into stable point releases) would allow us to have packages in main depend on packages in main/volatile (I think - ICBW). Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
Stephen Gran wrote: This one time, at band camp, Michael Tautschnig said: 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. A way around this problem might be to integrate volatile slightly more with the main dak archive. Treating volatile (from the point of view of dak) as a kind of proposed-updates queue (that may or may not get rolled into stable point releases) would allow us to have packages in main depend on packages in main/volatile (I think - ICBW). As what you call main/volatile is not in stable, I don't think that's a solution. The oposite would work though: packages in volatile depending on packages in stable (like with proposed-updates...). Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
On Mon, 2 Feb 2009 18:55:32 + Stephen Gran sg...@debian.org wrote: This one time, at band camp, Michael Tautschnig said: 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. A way around this problem might be to integrate volatile slightly more with the main dak archive. Treating volatile (from the point of view of dak) as a kind of proposed-updates queue (that may or may not get rolled into stable point releases) would allow us to have packages in main depend on packages in main/volatile (I think - ICBW). Couldn't we achieve the same result by just relaxing the policy of what's allowed in proposed-updates for clamav and rdepends with a lot less technical complexity? With the volatile approach you'd also have to exclude stuff not related to clamav from proposed-updates. Scott K -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
Michael Tautschnig wrote: 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. Mmmmk, then forget what i've said. It indeed doesn't make much sense anymore. To me, the approach of moving clamav + all its rdepends to volatile really looks like the only option. Yeah, I agree. -acab -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
[...] I maintain klamav. As I understand it, DM's don't have upload rights to volatile. I don't really have time to deal with sponsorship hassles currently, so I'd probably orphan the package. I don't think that these issues should be considered showstoppers for a move to volatile. I guess the upload-rights issue is resolvable, and finding a sponsor in the clamav team shouldn't be that hard :-) Best, Michael pgp7D822oRAeO.pgp Description: PGP signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
[...] We had discussed this during the Security Team meeting in Essen: We believe clamav shouldn't be included in stable; malware scan engines are a constantly moving target and it's pointless to backport changes since new signatures constantly require new scan engine features all the time. So moving it to volatile is the best solution for everyone. Ehm, its not a solution for me to move dansguardian to volatile only. It guess that counts for other applications that link against clamav too. Would you mind adding the rationale why this is not a solution for you? I'm not claiming that moving to volatile indeed is a solution, but getting some more insight would be nice. Thanks, Michael pgpQW4WYmJX00.pgp Description: PGP signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
[...] (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. Thanks, Michael pgpWzMRnYoWyT.pgp Description: PGP signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
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 Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
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 pgplijboKwU4V.pgp Description: PGP signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
On Sat, 31 Jan 2009 12:56:43 +0100 Michael Tautschnig m...@debian.org wrote: [...] We had discussed this during the Security Team meeting in Essen: We believe clamav shouldn't be included in stable; malware scan engines are a constantly moving target and it's pointless to backport changes since new signatures constantly require new scan engine features all the time. So moving it to volatile is the best solution for everyone. Ehm, its not a solution for me to move dansguardian to volatile only. It guess that counts for other applications that link against clamav too. Would you mind adding the rationale why this is not a solution for you? I'm not claiming that moving to volatile indeed is a solution, but getting some more insight would be nice. One question I have (I have not dealt with volatile before) is about support for multiple releases. Does it have separate pockets for stable and oldstable? Scott K -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
This one time, at band camp, Scott Kitterman said: One question I have (I have not dealt with volatile before) is about support for multiple releases. Does it have separate pockets for stable and oldstable? Yes, it's a (semi-)standard dak install, so it understands all the release stuff just like the main archive. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
On Wed, Jan 28, 2009 at 05:50:19PM -0500, Scott Kitterman wrote: I maintain klamav. As I understand it, DM's don't have upload rights to volatile. I don't really have time to deal with sponsorship hassles currently, so I'd probably orphan the package. So clamav is not sufficently modular to separate the library and the scan engines? Ho hum. Anyway I would not be glad if packages would be moved to volatile only without being present in unstable at all. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Release Assistant `. `' xmpp:p...@0x539.de Stable Release Manager `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
This one time, at band camp, Philipp Kern said: On Wed, Jan 28, 2009 at 05:50:19PM -0500, Scott Kitterman wrote: I maintain klamav. As I understand it, DM's don't have upload rights to volatile. I don't really have time to deal with sponsorship hassles currently, so I'd probably orphan the package. So clamav is not sufficently modular to separate the library and the scan engines? Ho hum. No, or at least not yet. There are two basic issues that can't be addressed with signature updates: support for new unpackers, and support for new signature types. I'm hoping once upstream gets support for all of the more common unpackers, things will settle down a bit, since the need to update signature types is less common. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
On Thu, Jan 29, 2009 at 07:01:38PM +, Stephen Gran wrote: This one time, at band camp, Philipp Kern said: On Wed, Jan 28, 2009 at 05:50:19PM -0500, Scott Kitterman wrote: I maintain klamav. As I understand it, DM's don't have upload rights to volatile. I don't really have time to deal with sponsorship hassles currently, so I'd probably orphan the package. So clamav is not sufficently modular to separate the library and the scan engines? Ho hum. No, or at least not yet. There are two basic issues that can't be addressed with signature updates: support for new unpackers, and support for new signature types. I'm hoping once upstream gets support for all of the more common unpackers, things will settle down a bit, since the need to update signature types is less common. Hi, I've been silently watching this thread for a while. Unfortunately I don't have much to add. Effective malware scanners belong to volatile, there should be no doubt about that. Even with the relativly short life cycle of etch we've ended up with a version of clamav in stable, which, basically, doesn't catch sh*t. The other question being asked is whether it makes sense to keep 3rd party tools which link libclamav under stable. And that's not an easy question at all... Starting from 0.95 we will see the very first attempt to stabilize the API/ABI (which historically has been a total disaster). Additionally, a sane set of default options will be employed for all those tools which are too old to be aware of more recent changes. However clamav is, in this regard, a very atipical project in that it lacks an ultimate development roadmap (or it has got very fast changing goals if you prefer). For example around 3 years ago a new functionality was added to detect phishing emails. The initial reaction was very mixed and was seen by many users as something outside the traditional scope of an AV. More recently a new experimental feature for data leak detection/prevention was added. In such cases, picking up reasonable defaults is not very easy. 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. Just my 2 eurocents, -acab -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The future of clamav wrt. stable/volatile
On 2009-01-25, Michael Tautschnig m...@debian.org wrote: --===6401238421216507687== Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=UfEAyuTBtIjiZzX6 Content-Disposition: inline --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Release Team, 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. - Do fairly large updates (i.e., possibly new major versions) through stable-proposed-updates. - ??? We don't necessarily seek a solution for lenny, but would like to start a discussion and receive some comments from people involved in release management to see which further options we have, or which of the proposed are acceptable. We had discussed this during the Security Team meeting in Essen: We believe clamav shouldn't be included in stable; malware scan engines are a constantly moving target and it's pointless to backport changes since new signatures constantly require new scan engine features all the time. So moving it to volatile is the best solution for everyone. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The future of clamav wrt. stable/volatile
Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009: On 2009-01-25, Michael Tautschnig m...@debian.org wrote: --===6401238421216507687== Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=UfEAyuTBtIjiZzX6 Content-Disposition: inline --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Release Team, 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. - Do fairly large updates (i.e., possibly new major versions) through stable-proposed-updates. - ??? We don't necessarily seek a solution for lenny, but would like to start a discussion and receive some comments from people involved in release management to see which further options we have, or which of the proposed are acceptable. We had discussed this during the Security Team meeting in Essen: We believe clamav shouldn't be included in stable; malware scan engines are a constantly moving target and it's pointless to backport changes since new signatures constantly require new scan engine features all the time. So moving it to volatile is the best solution for everyone. Ehm, its not a solution for me to move dansguardian to volatile only. It guess that counts for other applications that link against clamav too. Alex -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The future of clamav wrt. stable/volatile
Dear Release Team, 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. - Do fairly large updates (i.e., possibly new major versions) through stable-proposed-updates. - ??? We don't necessarily seek a solution for lenny, but would like to start a discussion and receive some comments from people involved in release management to see which further options we have, or which of the proposed are acceptable. Thanks, Michael PS.: Please keep the pkg-clamav-devel list CC'ed for other clamav devs to chime in. pgpPKyR80H3ks.pgp Description: PGP signature
Re: The future of clamav wrt. stable/volatile
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? 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. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-clamav-devel] The future of clamav wrt. stable/volatile
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. 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 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. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
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. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
