Hi! I'd like to excuse for the style of my initial response, it was pretty terse and just pointed out the misinterpretations without offering corrections to them. I'd like to address them now.
* Michael Gilbert <michael.s.gilb...@gmail.com> [2010-06-29 21:50:31 CEST]: > On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: > > You don't know the current policies WRT packages in backports and about > > their reasoning, do you? > > I believe I do. Backports are for recompilations of unstable packages > for the stable releases. Hence, that's why it seems like a good > solution here. volatile seems like it has a much more restrictive set > of criteria, but I suppose it would also be a good solution if its > allowable. That's not completely true. For a start, it's for recompilations for packages from *testing* (not unstable) in a stable environment. But reducing it to that is missing the point: The purpose of backports is to offer newer features in packages that are intended for the next stable release available for the current stable release. Wanting to put a package into backports as sole place won't get accepted because it won't be part of the next stable release. If we don't want to release a package it shouldn't go there neither. > Honestly, the ideal solution would be for either backports or volatile > to become officially supported (which from what I can tell has been in > discussion for a long time now). In fact, if one or the other did become > official, there would be no need for both. It might have evaded you, but volatile _is_ officially supported, for quite a long while already. See <http://www.debian.org/volatile/> about it, it uses .debian.org ressources directly. backports just started to get into there with being integrated into the official buildd network, things are progressing slowly. I only can see that you mean "officially supported *by the security team*", neither of them is, which is true. I am very grateful that the security-tracker does include the status for backports, though - that's extremely helpful to track issues. Additionally though, they are also both neither integrated into the BTS, which is another quite unfortunate state. But there is *need* for both: While backports is for getting newer features into stable for otherwise already good working software, the purpose of volatile is a completely different: It is about getting software into shape that does _not_ work anymore properly in stable anymore but would require deeper changes than just a small patch that could get in easily through a point release. Yes, clamav is a very good example here: The required engine changes are too much for a security/point release update, thus volatile is the proper place for it. I hope this clears up some confusion that might spin around in some heads. Thanks, and sorry for the initial response style again, Rhonda -- "Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder Mensch auch ein Privatleben haben sollte." -- http://www.karriere.at/artikel/884/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630100148.ga7...@anguilla.debian.or.at