[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?

[ownagefool]

You seem to be missing my original point. My understanding is you want to run the latest and greatest python, best practice is pretty much to use pip & virtualenvs(I'm not a python dev, so don't quote me on that). If you want stable, use the debian packages with security updates. Best of both worlds, like I said, but it's an either/or choice.

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.

[vacri]

Because it provides a stable environment for all packages outside of the special one you're personally managing.

[petsos]

If my server is web site running Django then the special one that I'm manually managing happens to be the most important one.