Debian Testing Tree Goes Online

A few people noted that Debian has brought the 'Testing' Tree on-line. So now we have Stable (currently potato) for production boxes, Testing (woody) for settling things down before an eventual release, and a new unstable tree for those of us who'd just rather things randomly break. Here's a bit more info if you're curious.

Comments

Re:respectable

[blakestah]

I think its great what they're doing. But, Isn't debian mostly alpha stuff. I mean it's always in the testing phases so what's the real point here?


Try running potato - the stable distro.

Woody is unstable. If you apt-get upgrade your woody regularly you will occasionally have some fun manual work to do. Like that upgrade last week that broke perl and thus debconf.

But the debian releases are in general more stable and MUCH MUCH easier to maintain than any RPM based distro. The packaging is just clean.

The reason the packaging is clean is simple. There are 644 Debian packagers, most of them system administrators running Debian for a living. It is human nature to be lazy, so these administrators each do their job on Debian so that their day jobs are easy and they can play quake while RedHat, Mandrake, and SuSE admins are resolving package dependencies and compiling unsupported packages from tarballs.

Now where is that Dubya patch for Quake again ...

Re:random things breaking not my experience

[jguthrie]

chasec wrote:

I used Debian woody for a while, but apt once installed perl-5.6, and it totally screwed up the dpkg config system. I had to go back to Mandrake (though I don't particularly like 7.2). Has anyone else had a problem with the perl 5.6 package? Is it fixed yet?

In order to understand the problem, you have to understand how Debian does (or at least "did") user-specific stuff. For anything where multiple versions were available, and for which end users might want to select which one to actually use, they set up links in /etc/alternatives and then another link in whichever directory is appropriate, usually /usr/bin or /usr/sbin for binaries.

Since there are multiple versions of perl interpreter out there, and since users might want to select between them, perl was done in this way so you might have /usr/bin/perl linked to /etc/alternatives/perl which would then be linked to /usr/bin/perl-5.005 or some such.

Well, the perl5.6 package deleted the link /usr/bin/perl and didn't replace it with anything. Since many of the install scripts use perl, this started breaking stuff during the upgrade that first included perl5.6. It took me a while, but once I noticed that install scripts were failing with "file not found" errors, I took a quick look and was able to verify both that the broken programs were perl scripts and that /usr/bin/perl was nowhere to be found.

So, I immediately created the symbolic link between /usr/bin/perl and /etc/alternatives/perl and re-ran apt, which fixed everything whose install was broken. Problem solved, and no reinstalling.

Since then, it appears that more recent versions of the perl5.6 package copy the actual perl binary into /usr/bin/perl (at least on the computer I use most, /usr/bin/perl and /usr/bin/perl5.6.0 have the same size and MD5 hash) so the problem does appear to have been fixed. However, I'm seeing some wierdness in woody that may be associated with the recent switch to package pools. (From what I understand, package pools allow files to move from "unstable" into "testing" without massive quantities of copying any time someone makes a change. This is a more significant development than a "testing" release, in my opinion.)

It's good to see the tree up

[Chuck Flynn]

It's good to see Debian got the tree up in time for Christmas. Soon we'll be decking the halls with boughs of Woody.

Testing is auto-generated

[divec]

Basically, the testing distribution is "maintained" by an automatic script, which contains all packages which have been in the unstable (i.e. development) distribution for two weeks without a release critical bug being filed, subject to satisfying package dependencies. The idea is that testing might be buggy, but should be up-to-date and not completely broken. See here for more detail and precision.