> This release includes numerous updated software packages, such as:
> Linux 3.2
> This release includes numerous updated software packages, such as:
> Linux 3.2
Zenwalk 7.2 has the 3.2.5 kernel.
What's the point of citing the kernel shipped with another distro here?
The tone of the top-level comment, I think, is "woah, Debian, you call this kernel updated?"
Rock-solid distros like RHEL/CentOS and Debian are deliberately conservative. Some folks don't like that.
https://access.redhat.com/support/policy/updates/errata/
So I don't think RHEL/CentOS can be compared here to Debian.
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?
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.
But if that works for you, then great :-)
Besides missing the origianl point, comparing pip to tarballs just seems wrong. One is pretty much manual, the other is via a package manager, albiet not the distro specific package manager, but one specific to the domain you are working within.
"But then why am I using Debian?"
Personally, I tend to stick with everything from debian direct, but there are lots of domain specific developers who'd rather have the up-to-date stuff and I can't entirely fault their desire when we're talking about real world benefits of new versions. You still benefit from the stable base even if you want to run something up-to-date. You don't see the benefit of that?
Going forward from that, you can still pip in specific versions, update projects seperatly, and obviously test them before doing so, so while you may lose some advantages, living in a specific pip world doesn't seem like the end of the world to me, as long as there's a positive reason for doing so.
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.
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.
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].
Change (well, poorly managed change) causes instability and issues. Debian has proven that they can manage change in their distribution and it makes everyones life easier.
I've been using CentOS 5.9 on a desktop quite happily, I just compiled R from source to get a more recent version. Worth mentioning that Iceweasel (aka Firefox) was on the ESR channel so getting updates fairly regularly.
The most common case:
v1 of a package is in Debian stable. v2 comes out, is uploaded to unstable, migrates to testing. Later, v3 comes out, is uploaded to unstable, but its migration to testing is temporarily blocked because it's waiting on a major upgrade, like a new libc version, to make it into testing, which typically is done in a carefully coordinated way.
Now a security issue is found affecting all versions of the package. The upstream will (hopefully) release a patched v3, which will immediately go into unstable. The Debian security team will backport the patch to v1, and make it available to Debian stable users on security.debian.org. But testing is still distributing a vulnerable v2. There is typically no process to specifically patch v2 just for testing, because testing is staged via migrations from unstable; the usual situation is just to wait for blockage to clear and for v3 to migrate. There are occasional exceptions, mostly near releases: if it's determined that v3 won't be able to migrate before the next stable, a specially patched v2 may be uploaded to testing to get it into the next stable.
That scenario doesn't happen that often, but it's worth being aware that testing can lag behind both stable and unstable in security updates.
Sorry for the misinformation!
I just found from your link that I had no security repo configured. Just added:
deb http://security.debian.org testing/updates main
UPDATE: Here is a more correct set of settings from http://secure-testing-master.debian.net/ :
deb http://security.debian.org testing/updates main contrib non-free
deb-src http://security.debian.org testing/updates main contrib non-free
Even though they claim that contrib and non-free have no security updates, they are listed for some reason.
http://www.debian.org/vote/2013/platforms/lucas
I hope they'll tackle this security issue.
Also, you can have newer kernels in the debian backports repo.