[petsos]

And that I think is the biggest problem of Debian. They aim stability but how can you possibly claim that your custom backports are stable when e.g. the original developers have stopped supporting it?

They may be able to pull it off with the kernel, but they can't possibly do it for all their packages. As an example: How are the Django backports to 1.2 more stable than upgrading to 1.3 when the official Django project has stopped supporting 1.2?

[rogerbinns]

Who says the original developers stopped supporting it? Head on over to http://www.kernel.org and you'll see that 3.2 has longterm support (ie the kernel developers backport relevant fixes and patches). There are more details at https://www.kernel.org/releases.html including end of life dates. Given the time span between Debian releases, 3.2 is an excellent choice, if not the only one.

[petsos]

Right, this may be true for the kernel, but it can't be and it is not true for all of Debian's packages. Case in point Django: https://docs.djangoproject.com/en/1.5/internals/security/

Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fix into the unsupported 1.2. And this is deemed more stable than say, upgrading to 1.3.

Note that Django is just an example, obviously there are many more packages with the exact same problem.

[claudius]

If the Debian maintainer has any idea what he’s doing, then this is likely to be more stable than upgrading to a new release that introduces new features and possibly incompatibilities. Fortunately, most Debian maintainers have a very good idea of what they’re doing.

[petsos]

Likely yes. But if I had to choose between the original developers and someone that has to maintain 20 different packages, I will chose the original developers.

[claudius]

I imagine few maintainers to maintain 20 different packages, and if they do, they are likely related in some way – and then I trust a Debian maintainer more to gauge the impact of a new version on the system than some upstream maintainer, who likely even uses some other distribution.

But if that works for you, then great :-)

[tshepang]

"stable" does not necessarily mean "better"; In the case of Debian, it can mean "unchanging"... that is you can rely on it to not break your software even if you keep it ("stable") updated.

[petsos]

True, but a security update means both better and more stable.

[belorn]

Security fixes that addresses issues in 1.2 will be back-ported from 1.4 by either A) upstream, or if that fails B) the Debian maintainer, or if that also fails, C) Debian security team. Thats the promise made by The Debian security team which cover the latest stable major release, and for the prior stable release for one year.

And it works. Most of all fixes are done by A or B, but the promise is one which the security team takes very serious. For one release, the security team backported security updates for 4 years. A achievement of taking responsibility in a "open source" project if I ever saw one.

[ownagefool]

For the record, debian also packages up pip and you can install an up-to-date django using that. You essentially get the best of both worlds here.

[petsos]

Well, it also packages tar and I can untar and install any package from source.

[ownagefool]

I dare say that's not really an apt comparison if you're going for sarcasm. If you're being serious, then um... yeah.

[petsos]

How is it not an apt comparison? What pip would do in this case is bypass apt and install the latest version of Django and its dependencies. If I'm going to do that I might as well build the database and server from source too to have the latest versions. But then why am I using Debian?

[csirac2]

I used to be all for the way backports are handled, until I had an excruciating experience with a perl module recently (the Locale::Maketext vulnerability). 1.19 is vulnerable, so they "backported" the CVE change, without realizing that this means their franken-1.19 version is exactly the same code now as the latest 1.23. All that's different is the POD and $VERSION.

Which sucks, because application software needs to handle environments with Locale::Maketext 1.19 differently to environments with 1.23, else you get double-escaping bugs.

The response? Reporting the actual, correct module version (or god forbid, sync the comments/POD as well) instead of the incorrect, unchanged version number "would break stuff". As opposed to incorporating a breaking API change without bumping module version, which also breaks stuff... Ouch.

I guess I only have myself to blame, I should be more involved with debian maintenance of packages I care about.

[pfg]

That's one of the reasons why I try to get as much software from the actual developers as possible, instead of relying on packages maintained by [Debian|Ubuntu|Red Hat|...].

Obviously this is a lot of work (patches, managing dependencies, ...) if you do it for everything, but if you stick to the most important packages (e.g. nginx for your webserver, postgres for your db server, ...) I think it's manageable and will give you a lot of benefits.

(Thinking about the Debian OpenSSL fiasco a few years ago, I guess one could make an even stronger argument, though to be fair it was a pretty extreme case and I don't think anything like that has happened since back then.)

//Edit: I got curious about the OpenSSL issue from 2008 and it turns out that the Debian maintainers weren't solely responsible for the bug[0].

[0]: http://research.swtch.com/openssl