Is Debian 'lenny' aka 'testing' suitable for production environment?
 

I've been using 'testing' branch for production servers for quite awhile. However, recently I noticed packages are disappearing from the 'testing' branch. Eg. Heartbeat-2. Heartbeat-2 was found in 'testing' branch until a few weeks back.

Will this trend continue and what if I do a 'aptitude update;aptitude upgrade;aptitude dist-upgrade'? Will it uninstall the heatbeat-2 package that is currently installed on my servers?

Thanks !

Debian is so rock solid that their testing versions are usually more stable that some other distros' release versions. However, for anything really, really important, I would stick with Etch.

Luck!

It is possible the heartbeat package has been migrated into another package, or like Debian likes to do, change the name "Firefox" to "Iceweasel", might have to do a little research to figure out what happen to it. And as stated above, Debian testing is "Rock solid".

Usually. The day a major change happens (i.e. xfree86 -> xorg), testing can become a bit of a gong show. It's a surprise I wouldn't want in a production environment, and would probably stick to etch.

Been using testing for quite some time, never seen any gong shows here, just stable performance. And I work my Debians to the bits, they handle the loads my Red Hat derivatives choke and freeze on.
EDIT: Based on your example of the transition from Xfree86 to X11, you must have done a distribution upgrade, not testing upgrade.

NO. For a production server use Stable.

Using testing or unstable in a production environment is kinda silly if you ask me. For a desktop or non-critical things Testing or unstable is fine, they are more stable that the names imply, but for a production server I wouldn't even consider it.

I suppose it depends on what kinds of things you're doing and what sort of system you have. Right at the moment a lot of new packages are flowing quickly into testing and there has been a lot of breakage on desktop systems (problems from xorg, nvidia, ati, etc.). The reputation of "Debian testing as most distros stable" can be misleading. I think it comes from Etch (old testing) being so incredibly solid as it took its time to become new stable, but a newer testing Debian may be rocky again. For a production server I would stick with Etch.

Checking heartbeat
trying to update heartbeat from 1.2.5-3 to 2.0.8-9 (candidate is 16 days old)
heartbeat is waiting for curl, net-snmp
Updating curl makes 169 depending packages uninstallable on i386
Updating curl makes 111 non-depending packages uninstallable on i386

More details here.

Are such problems common for packages in testing branch?

Thanks.

Yes, Even for a distribution like Fedora, where one team puts out an update to the kernel for example, another team like livna has to put together a new kmod-nvidia package matching that new kernel, sometimes the second team may be a little busy and their package is slightly delayed. The first team will carry on posting the updated kernel because they also are busy and have a long list of things to do and need to show a certain amount of completion on a timely basis.
A stable version distribution does not upgrade packages, only bug fixes and security fixes that usually does not have different teams involved.

Another little "surprise" will be coming up soon, when the 2.6.21 kernel gets into lenny. If you have any /dev/hd*s, they will become /dev/sd*s, so you should make a mental note of this and remember it when your system won't boot after a dist-upgrade!

Of course you can avoid this by using labels, or better yet stick to etch for a production environment. That's what it's there for, after all.

Exactly what happened a few days ago on FC7.

They forgot a dependency and the kernel could not be updated. It was solved the day after.

I wouldn't use a testing branch for production. If you really need some packages from testing, either backport them yourself or find somebody who has done it.

Don't forget that the libATA drivers that force the kernel to see every device as a SCSI device (sd*) also will force the SCSI 15 partition limit on all hard disks. I recently had this problem in Zenwalk. I have 18 partitions on one of my drives. hda18 is my distro-common storage partition. hda17 is my /swap on that drive. Zenwalk couldn't see either. I had to custom compile a kernel with IDE support to eliminate this problem.

The libATA driver system being instituted in newer kernels has its advantages, but for folks like me, who use large drives with more than 15 partitions, it SUCKS!

I use bootitng, my shared data partition is allocated high on the drive, I can create 253 primary partitions in front of it on my SCSI SATA drive and the kernels of the Linux systems don't see most of them, currently my data partition is the 20th primary partition. When I type: fdisk -l, the only partitions that show up are the three I allow that system to see, which is it's root, shared swap, and the shared data. So the SCSI SATA nameing convention does not affect my multi-boot on a large drive.