backports and volatile (was: Re: xulrunner 1.9.2 into sid?)
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.gilbert@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/
Reply to: