[homeomorphic]

Really? I've always felt that they give me the perfect balance: the distro itself is non-rolling, so breakages (possibly) happen at known intervals, yet PPAs let me "go rolling" for a subset of packages where I want the latest and am prepared to handle breakage at any time.

[gizmo686]

I wonder if there is a way to build this process more into the package management system. Maybe have to sets of repositories, a 'stable' repository that would behave like current, non-rolling repositories, and a 'rolling' repository that would get new versions of software once they've been tested. By default, software would install from the stable repositories, but you can do something like 'apt-get make_rolling python', and get the rolling release version of python. Such a system should then be able to handle dependencies that would need to be made rolling as well.

This clearly means more work for the maintainers, but only because the PPA method is so clearly a hack that there is no expectation that it must just work.

[sciurus]

This is similar to what the backports repository provides, After you add the repository, apt does not install anything from it by default. Instead, you have to tell it to, e.g. apt-get -t squeeze-backports install "package"

https://help.ubuntu.com/community/UbuntuBackports

http://backports-master.debian.org/

[qznc]

Apt supports this. However, no distribution officially supports that scheme.

http://wiki.debian.org/AptPreferences

http://serverfault.com/questions/22414/how-can-i-run-debian-...

http://blog.drewwithers.com/2011/06/mixing-debian-stable-and...

Debian stable + backports is probably closest. Unfortunatelly, there are few backports. Partially, because few people use it and partially because upstream rarely cares for Debian stable.

[sp332]

Can't you do this with Synaptic? Include apt lines for multiple versions, then select "prefer versions from Oneiric". That lets you force a version for specific packages while not updating the whole system.

[gtaylor]

You really are at the mercy of the PPA maintainer, too. For some packages, the maintainer's interest may not be there for more than a release or two. That's a pain, when I could just be pulling from multiverse/universe/whatever it was called.

Obviously, this is less of a problem with the more popular PPAs (Postgres, for example).

[sp332]

PPAs should be for cutting-edge stuff, not stuff that was stable 4 months ago and hasn't been updated in "main" yet.

[homeomorphic]

But "stuff that was stable 4 months ago" is not a trivial case either. Suppose A version 1.1 was stable 4 months ago, but that the version of B that works with A 1.1 is horribly buggy still, and the stable version of B needs A 1.0. Do we upgrade A? I can imagine this becoming very tough to mange with 20k-30k packages. I hope Canonical can deal, but I do fear that the users will suffer.

[sp332]

If it's a library, it should be trivial to have the latest A 1.1 installed alongside older A 1.0 and stable B.

[homeomorphic]

With potentially hundreds of different packages playing the role of B, this could eat up a lot of manpower. What if the breakage is subtle and not well known upstream? While it could work, it sounds like something that would take a lot of QA work by Canonical.

[Avshalom]

That problem already exists, except currently there is generally a six month minimum before it gets resolved.

[homeomorphic]

> That problem already exists, except currently there is generally a six month minimum before it gets resolved.

I view it differently: Currently, the situation doesn't unexpectedly change for six months :-)