LWN: Comments on "A constantly usable testing distribution for Debian"

A constantly usable testing distribution for Debian

crimsondebian — Mon, 11 Oct 2010 04:03:44 +0000

It would be worth to take a look at Parsix Linux (www.parsix.org), it is based on testing, but they keep their own copy of the repository in their servers and freeze it then test it, and finally make a release. I think it is a good combination too: making a cycle release distro based on a rolling release one .

A constantly usable testing distribution for Debian

arpadapo — Wed, 06 Oct 2010 00:55:02 +0000

I do, for instance.

I have two computers, one is a desktop with Lenny (stable) and the other is a laptop with Squeeze (testing). However, there are several virtual machines on both, so I can actually use something newer whenever I want. Or when I have to care about security more than usual. (Good example is web browsing sometimes from Sid in VirtualBox, using the latest version of Firefox plus the necessary addons.)

A constantly usable testing distribution for Debian

BackSeat — Tue, 05 Oct 2010 13:31:20 +0000

If upstream releases a new stable version, then assume it's a _stable_ version and thus _immediately_ include it as an update to the stable distribution.

The reason we run Debian Stable on a large number of servers is precisely because Debian does not make such assumptions.

That sort of thing may be OK for a desktop distribution, but when running customer critical applications on a server in a data centre, stability and security are far more important than "the latest version".

Exaggeration

dererk — Tue, 05 Oct 2010 13:19:29 +0000

You are mixing a lot of real facts, but using them as your own purpose.

That is, following your understanding, Red Hat Enterprise Linux offers a 4 years old distribution (because they distribute 2.6.18 kernel which was realized 14th Oct 2006), or, in the same way, it's 6 years old, because it includes python 2.4 released on 2004...

It's a stable software, in software engineer that would basically mean it has been proven to work in most testing scenarios, unfortunately for some cases, *that time* is too much.

I really think CUT would be a solution for them. Once again, thanks JoeyHess the great tools you invent and code (altogether with etckeeper, debconf itself, and so on!)!

Delta .debs

riteshsarraf — Sun, 03 Oct 2010 10:10:15 +0000

Debian already has provision for that.
http://debdelta.debian.net/

Delta .debs

Richard_J_Neill — Thu, 30 Sep 2010 21:34:58 +0000

One other desirable condition for this to work (imho) is to support Deltas (i.e. patches) rather than full debs.

For example, a ten line code-change in one of the core libraries can snowball into updates of 50 packages, and a 200 MB download of .deb files, even though the actual end result could be established with rsync in a few MB.

This is expensive and time-consuming for mirrors and users alike.

Suggestion: user has currently got version example-2.5.3 installed, and the latest release is example-2.5.4.

Current process: download example-2.5.4.deb.

Better suggestion:
- User keeps the previous 2.5.3.deb (disk space is cheap).
- Mirror has example-2.5.4.deb AND example-2.5.3_2.5.4.patch
- User then downloads the much smaller .patch file, and re-generates the latest .deb locally.

Major advantage for bug reporting

Richard_J_Neill — Thu, 30 Sep 2010 21:26:06 +0000

This would be a fantastic solution to the bug-reporting dilemma, because it shortens the cycle.

Consider the following case, of a technically skilled user running CUT.

1. User finds bug/issue/missing feature/suggestion in a particular app.
2. User files bug report.
#Because this is CUT, not stable, the bug report is valid and useful
#to the developers, without them having to utter the usual,
#understandable "but are you running the latest code".
3. Bug gets fixed in upstream.
#User gets the bugfix in a reasonable timeframe; this means he benefits
#from better software, and it's highly motivating for him to continue
#being involved.

Contrast 2 other, more typical cases.

(a) Stable distros. Most showstopper bugs are ironed out. But there are always some that remain. Frequently, these are fixed upstream, but never backported. And if the user files a bug report, the devs often find it not-useful.
#User is never able to run "perfect" software; he lives with one set of
#bugs for 6 months, then upgrades distro version, and gets another set.

(b) Unstable distros. These are unusable as a daily system for the vast majority of users, because there is frequent critical breakage.
#The majority of the talented Linux "eyeballs" are thus dissuaded from
#working where they can do the most good.

A constantly usable testing distribution for Debian

ummmwhat — Thu, 30 Sep 2010 18:19:36 +0000

Finally!
I'm not sure how it took 17 years to realize this obvious need (perhaps even the most basic one!).

I think it's simply silly that Windows users can just download new software, while Linux users doing distribution updates (which is what they are supposed to do) have to wait up to 6 months for new software.

The solution is simple: try to trust upstreams.
If upstream releases a new stable version, then assume it's a _stable_ version and thus _immediately_ include it as an update to the stable distribution.

If any upstream is caught releasing "stable" releases that are not suitable for being updates to stable distributions, then _complain_ to upstream loudly, _help_ them get better QA polices, and delay their updates as is done now until the process issues are fixed.

For security updates, it's also simple: just use the update provided by the upstream.
If upstream refuses to release a stable version with the security update, complain, help and delay updates as above.

In other words, just stop attempting to duplicate stabilization work in every distro by forking all packages, and instead tell the problems upstream and help them make better releases.

Exaggeration

pboddie — Thu, 30 Sep 2010 17:49:58 +0000

But it's going to be way outdated at release time, if you take some specific high-profile examples:
- Python 2.6 (not 2.7, released Jul 3)

I suppose using something like Python 2.5 (as I do on the semi-supported Kubuntu 8.04 release) occasionally results in brushing up against code written needlessly against Python 2.6-or-later features, but quite a lot of that can be fixed quite quickly, especially if that code is limited to people doing stupid things with setuptools instead of just providing sane distutils stuff in their setup scripts.

Really, Python 2.6 is the launchpad release for people jumping to 3.x, with 2.7 being the successor in that regard, plus extra gravy.

Your other examples are somewhat better, however, although there's almost always a case to be made for holding back on the newer stuff, especially if adopting such stuff means several laps of the track for those having to integrate and test it with everything else.

Constantly Updating Testing

pkr — Thu, 30 Sep 2010 07:41:42 +0000

This doesn't sound very attractive to me. I'm running Debian/stable on one
of my desktops and switched to Debian/testing just recently on another
because I wanted a newer Version of PyQT. But switching to testing was
no fun. The next time when I want a newer Version of any software
than the one installed, I will just install it in /usr/local and
remove the installed outdated package. I will do that for any
other software until only essential packages are left.

It looks like Debian doesn't know what to do with releases, they have
volatile, backports and numerous unofficial projects (like debian-
desktop.org), trying to solve the problem they have with
releases. This proposal sounds like a good solution but only if
they would also give up trying to get a real release ready and leave
that for others like Ubuntu.

Agreed, unstable gives me very few problems

cypherpunks — Thu, 30 Sep 2010 07:05:24 +0000

And I've been using it on production servers since 2000. The biggest pain I remember is CUPS. It's still an opaque Windows-inspired piece of monolithic crap, and there have been month-long periods when new releases didn't work for mysterious undiagnosable reasons.

But other than that, I upgrade a few times a week and have only had a few glitches.

Bleeding-edge is "experimental". I've used packages from there occasionally.

A constantly usable testing distribution for Debian

misiu_mp — Mon, 27 Sep 2010 14:46:10 +0000

They do, dont they? I thought arch had this kind of release model, but I wasn't sure.

I definitely like the ability to upgrade software to the next great version, instead of being stuck with old and outdated one, however secure and stable it might be. This is especially valid for typical user-level applications, where features are important such as OO.org, firefox, eclipse, gimp, games, multi-media, version control clients etc. These usually are the leaves of the dependency tree and can easily be upgraded. If they break, they don't affect other packages and can be replaced simply with new versions.
It is usually less important to be up-to-date with the core packages such as kernel, gnome, glib, dbus and such. For those it is more important to have stable versions. As long as it is possible to use the latest features of my user programs for work or whatever, stable core is a good core.

That sounds like a good idea for a distribution - cutting edge user programs (with several versions to choose from) and a stable, hardened system core.

Exaggeration

juliank — Sun, 26 Sep 2010 14:34:47 +0000

> Ubuntu 10.10 already has Python 2.7
But it's not the default and not supported, so practically useless.

> Ubuntu 10.10 already has gcc 4.5
It's not the default, so it does not matter.

Debian has those packages as well, in experimental. In Ubuntu, there is no thing such as experimental, so it needs to be in maverick in order to be in Ubuntu.

Exaggeration

pgquiles — Sun, 26 Sep 2010 14:15:23 +0000

>> - Python 2.6 (not 2.7, released Jul 3)
>Same for Ubuntu 10.04 and Ubuntu 10.10.

Ubuntu 10.10 already has Python 2.7

http://packages.ubuntu.com/search?keywords=python2.7

>> - GCC 4.4 (not 4.5, released Apr 15)
>Same for Ubuntu 10.04 and Ubuntu 10.10; moving to a new GCC version is >usually a bit complicated.

Ubuntu 10.10 already has gcc 4.5

http://packages.ubuntu.com/search?keywords=gcc-4.5

If Ubuntu can develop something quite stable with 6-month release cycles and 2-month stabilization cycles, why can't Debian try it? (openSuse has 9-month release cycle and also works well for them)

A constantly usable testing distribution for Debian

giraffedata — Fri, 24 Sep 2010 18:04:40 +0000

A lot of people also want their desktop and notebook to work without fussing over them every day, so run Debian stable there too. I do. Once, I found I wanted some features that were too new to be in Stable, but I decided to wait a year rather than risk a maintenance headache.

Rackspace rents virtual machines running any of about a dozen Linux OSes. Stable is the only Debian option it offers.

A constantly usable testing distribution for Debian

danieldk — Fri, 24 Sep 2010 15:09:29 +0000

I would love this, because it would be easier to recommend Debian to less technical users. I never really recommend friends or family to use Debian Stable (since they expect newer applications), and I woudn't dare to recommend them testing or unstable. So, Ubuntu is usually the best compromise. But having a constantly usable testing distribution would put Debian back as an option.

A constantly usable testing distribution for Debian

oak — Thu, 23 Sep 2010 21:21:37 +0000

Yes, on my desktop. At home and at work.

On my home laptop I run Debian old-stable[1] as the newer SW in Debian stable was memory usage wise too bloated for it.

[1] Note: its PCMCIA network card broke before Lenny became stable, so I don't worry about remote exploits and as I don't have any valuable data on it, I've pasted the password on its cover. I use it fairly rarely, mainly to do some C/Python coding & TeX writing when not at home. If somebody steals it, they are going to be responsible for recycling it. :-)

A constantly usable testing distribution for Debian

gidoca — Thu, 23 Sep 2010 16:24:07 +0000

Rolling releases aren't quite that unique. Gentoo and Arch have had them for a long time, and I wouldn't want to use a distro on a desktop that doesn't have rolling releases. I really hope Debian decides in favor of them.

Exaggeration

juliank — Thu, 23 Sep 2010 15:04:21 +0000

> Well, it depends on how you count. For example, Debian Squeeze is not yet
> released. But it's going to be way outdated at release time, if you take
> some specific high-profile examples:
> - Python 2.6 (not 2.7, released Jul 3)
Same for Ubuntu 10.04 and Ubuntu 10.10.

> - Linux 2.6.32 (not 2.6.33-2.6.35, 2.6.33 released Feb 24)
Well, 2.6.32 will be maintained longer than 2.6.33, 2.6.34, or 2.6.35; and makes much more sense for a Debian release.

> - GCC 4.4 (not 4.5, released Apr 15)
Same for Ubuntu 10.04 and Ubuntu 10.10; moving to a new GCC version is usually a bit complicated.

> - Firefox 3.5 (not 3.6, released Jan 21)
> - Thunderbird 3.0 (not 3.1, released Jun 24)
Mozilla stuff is generally a problem, as far as I know.

A constantly usable testing distribution for Debian

foom — Thu, 23 Sep 2010 15:00:45 +0000

> Two month ago, I tried to install Squeeze on a new laptop. Neither the ethernet nor the wifi were supported, and that can make a netinstall very hard to do.
> Both were supported in 2.6.33 but were not yet added to 2.6.32.

If you submit a bugreport, it might get added.

A constantly usable testing distribution for Debian

Seegras — Thu, 23 Sep 2010 13:34:37 +0000

On servers. A lot of servers. Everything else (well yes, everything including RedHat, SuSE, *BSD, Solaris and of course #@!dows, except maybe Ubuntu LTS) is just a nuisance. You want them to work, and you want them to have all the necessary security-patches, but you don't want to fuss over them every day.

Otherwise, on my workstation and notebook, I use "unstable".

Problems with clusters of related packages

Np237 — Thu, 23 Sep 2010 13:10:50 +0000

Please dont hesitate to report such issues. It often happens that we miss some of the inter-package dependencies in unstable, and they get only noticed when the package enters testing.

This is where testing migration beats us hard, since the packages with fixed dependencies will not migrate until their dependencies do, so testing users remain screwed.

I feel this is one of the major challenges that needs to be dealt with by CUT.

Exaggeration

dbruce — Thu, 23 Sep 2010 12:42:44 +0000

Good points - the stabilization process seems to add an awful lot of time.

DSB

A constantly usable testing distribution for Debian

jengelh — Thu, 23 Sep 2010 12:37:03 +0000

Over my dead body! :-D (Seriously, RHEL has already beaten Debian stable in terms of outdatedness.)

A constantly usable testing distribution for Debian

algernon — Thu, 23 Sep 2010 09:45:23 +0000

I run stable on all my servers - for most of the time anyway. I usually start to switch my servers one by one to testing halfway through freezes, though.

A constantly usable testing distribution for Debian

micka — Thu, 23 Sep 2010 08:03:07 +0000

Two month ago, I tried to install Squeeze on a new laptop. Neither the ethernet nor the wifi were supported, and that can make a netinstall very hard to do.
Both were supported in 2.6.33 but were not yet added to 2.6.32.

Anyway, I always update to unstable right after the end of testing install (read minutes after). Testing is outdated as soon as it freezes (sometimes even before).

A constantly usable testing distribution for Debian

gwittenburg — Thu, 23 Sep 2010 07:34:32 +0000

+1 on that one! :)

A constantly usable testing distribution for Debian

cjwatson — Thu, 23 Sep 2010 07:00:14 +0000

I didn't say that you would be able to use CUT everywhere you can use stable; that was not my point. My point was that the *process* of preparing regular CUTs would help us with releasing stable in a more timely fashion.

A constantly usable testing distribution for Debian

a9db0 — Thu, 23 Sep 2010 03:59:04 +0000

aptosid is focused on being derived from Sid, which is the unstable branch of Debian. It's far more bleeding edge than Testing. (Current kernel - 2.6.35) It's very nice for those of use who like to hang out on the slightly-hairier edge.

I currently use it on my desktop and laptop. I started on the laptop because I needed the very up to date kernel for harware support, and I wanted to try an XFCE desktop. Liked it so much I moved my desktop to it.

Problems with clusters of related packages

JoeBuck — Thu, 23 Sep 2010 00:57:51 +0000

Back when I tried running Debian testing, I had major difficulties whenever there was a Gnome transition (I think KDE had the same issue), in that packages would trickle in individually, resulting in a mostly unusable desktop because Gnome wouldn't really run with an arbitrary mix of older and newer packages with a few left out, regardless of what the dependencies say. It's been a while so maybe the Debian folks have figured out how to make this work better, but I somehow doubt it. Probably the only way to really get it right is to identify groups of packages that have to all move into testing together, even if the raw .deb dependencies say that there is more flexibility.

A constantly usable testing distribution for Debian

copsewood — Wed, 22 Sep 2010 22:54:58 +0000

I run Debian stable on a cheap virtual machine server and have done so for several years, achieving around 99.9% uptime ( perhaps 3-4 hours downtime per year, and nearly all of this downtime is planned in advance). Not bad for a £15/month server.

A constantly usable testing distribution for Debian

marcH — Wed, 22 Sep 2010 22:31:59 +0000

> Does anyone run Debian "stable"?

If not, who would run Redhat?

A constantly usable testing distribution for Debian

SiB — Wed, 22 Sep 2010 22:31:39 +0000

Once or twice a year I had to fix something on a text console after an upgrade. Only once ever I had to init=/bin/bash to recover from some breakage. I try to avoid an upgrade if I know I need the computer during the next few days. And I never upgrade all computers at once. So, Debian sid is pretty stable, from my point of view.

A constantly usable testing distribution for Debian

foom — Wed, 22 Sep 2010 22:22:50 +0000

> New hardware is not supported

Actually that's not true. The stable kernel updates *do* include new hardware support, where it's possible to backport in a reasonable way. For example, the onboard ethernet card in my desktop (running lenny) wasn't supported in the original kernel, but is now.

For etch (the one before lenny), they even released a new upstream kernel partway through the stable cycle which could be optionally installed.

Exaggeration

foom — Wed, 22 Sep 2010 22:20:21 +0000

Well, it depends on how you count. For example, Debian Squeeze is not yet released. But it's going to be way outdated at release time, if you take some specific high-profile examples:
- Python 2.6 (not 2.7, released Jul 3)
- Linux 2.6.32 (not 2.6.33-2.6.35, 2.6.33 released Feb 24)
- GCC 4.4 (not 4.5, released Apr 15)
- Firefox 3.5 (not 3.6, released Jan 21)
- Thunderbird 3.0 (not 3.1, released Jun 24)

So, by your measures, Squeeze is not yet 0 years old, but if you measure by firefox version included, it's already 8 months out of date and it hasn't even been released yet.

I don't have a major problem with that; I use Debian on all my machines -- stable (lenny) on most of them. And basically the only software I've upgraded on those is emacs23 and linux 2.6.32.

But it does seem somewhat of a shame that it takes so long to stabilize things and get a release ready after starting to freeze packages, that much of the software is 6+ months out of date at the day of release. Maybe CUT will help with that.

Exaggeration

Cyberax — Wed, 22 Sep 2010 22:09:36 +0000

"No, it has never been more than 3 years old."

You're forgetting the time spent in pre-release freeze. For example, Lenny has Linux 2.6.26 which was released on 13 Jul 2008. So it's already 2 years old and is going to be about 3 years when Squeeze is going to be released.

Python 2.5.2 (in Lenny) was released on Feb 18 2008 - already more than 2.5 year old.

Exaggeration

dbruce — Wed, 22 Sep 2010 21:50:08 +0000

"Debian Stable rapidly becomes woefully obsolete - it's usually about 3-4 years old."

http://en.wikipedia.org/wiki/Debian#Release_history

No, it has never been more than 3 years old. The only time it was ever over two years old was between July 2004 and June 2005 (due to the infamously-delayed Sarge release). Until 2002, Debian released a stable distro every year. Since Sarge, it has been just under two years between releases.

So in recent years, Stable has always been between zero and two years old, with the mean age being about a year.

DSB

A constantly usable testing distribution for Debian

dlang — Wed, 22 Sep 2010 21:46:24 +0000

yes they do, especially on servers.

they don't always stick to only the versions of the packages supplied by Debian though.

I run debian on a few hundred systems, but there are a half dozen or so packages that I consider critical and run more up-to-date versions of (the kernel being one of them)

A constantly usable testing distribution for Debian

ms — Wed, 22 Sep 2010 21:43:45 +0000

Weird - I've been using debian unstable for about 9 years now on all my desktops and some servers. I very rarely have any problems.

Now admittedly, my requirements are light - ratpoison, mutt, xterm, chrome (was firefox) and emacs are pretty much all I actually require, and I've only recently taken to running gnome in the background.

Given I have little experience of where these constantly breaking packages come from, can people enlighten me? What does break so frequently? - is it just the latest shiny stuff or have I just been very very lucky?

A constantly usable testing distribution for Debian

paravoid — Wed, 22 Sep 2010 21:41:45 +0000

Are you really asking that? Several people (and companies) do, on hundreds of thousands of machines.