Re: Why back-porting patches to stable instead of releasing a new package.
Quoting Luca - De Whiskey's - De Vitis (luca@debian.org):
> My point is: i understand what said in that paragraph, but what if new version
> is a bugfix release that does not address only a secutiry issue? I'm not sure
> that system administrators would like to have a buggy package on their hosts
> with a security bug fixed, but with many other open nasty bugs.
The same happened with one of my packages: snort. There was a /really/
old release in stable, because new uploads didn't make it in time. There
were a couple of reasons why it would be good to have a new upstream
version of the snort package installed in stable. But the Debian Policy
forbids it.
Even though the new snort package would mean better intrusion detection
for the user, tons of bugfixes to the package and the source AND two or
three security fixes.
I do understand the reason, as new versions also introduce new bugs, but
in this case that wouldn't really matter because the snort package that
is in stable is so broken it sometimes even won't work ;)
Anyways, what I did was create backported packages, and put them on
p.d.o/~ssmeenk/. Unfortunately now people just assume that i'm going to
backport every (package)release to unstable to stable, testing and
old-stable.
> IMHO, these points should be relaxed while speaking about bugfix package
> release.
I think Q&A (or others) should take such a package and test it
thorougly, and then maybe decide to put it in stable. Unfortunately such
a thing takes a lot of time and work. So really, putting your own
backported packages on p.d.o seems like the best option.
Sander.
--
| One tequila, two tequila, three tequila, floor.
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Reply to: