Linux distro/version to support when releasing a software on Linux.

Question

We are about to release a couple of softwares with Linux support.

As for Mac and Windows, the number of version to support is quite limited (xp, 2000, vista, 7 for win, 10.4-6 for Mac). But for linux it's another story.

We'd like to support as many Linux as possible, but the choice is large.

The questions are:

• Which distribution format (binaries) to use to support as many Linux as possible?
• For testing, what "base linux" can we test on and extend our results to other linuxes.
• According we provide statically linked binary with all the dependencies, what do we need to check? I assume kernel version and libc version, but I'm wondering.

Our software is written in ANSI compliant C with a bit of BSD and POSIX (gettimeofday, pthreads).

Answer 1

So you think three versions each for Mac and Windows is normal, but you shy away from Linux? Hm.

Just make sure it builds using the standard tool chains -- configure, make and make install traditionally. The rest should take care of itself.

Else, pick what you are comfortable with. For me that would be Debian/Ubuntu, others prefer Fedora. Look at the Linux Standards Base and things like FreeDesktop.org for other standards. Kernel and libc should not matter unless you are doing something very hardware or driver-specific.

Answer 2

The kernel strives to maintain a backwards-compatible binary API. Statically linked binaries built against 1.0 series kernels are supposed to still run fine to this day on the latest 2.6 series kernels.

If you are statically linking with everything (including libc), then the major problem you are likely to face is different filesystem arrangements, which may not even be a great issue for you. (Testing is the only way to find out, though).

Answer 3

An idea is to survey your proposed customer base so see which linux version they run and make a short list from their feedback. However from what I know (which is subjective!) ...

I would suggest running two different distribution types -- rpm and .tar.gz. With rpm you cater for the latest Fedora/openSUSE/RHEL/SLES (and derived distros, which is a fair chunk of the corporate market). You are already handing a lot of dependency problem by static linking, so kernel version should be sufficient.

With .tar.gz distribution you cater for 'all others' but watch support and configuration problems as they quickly become a time sink.

For testing, have virtual machines of each version you choose to support. These can also be used for product support (I assume you will need to provide product support??) I wouldn't try to extrapolate results between linux versions because there a too many hidden 'gotchas'.

Answer 4

You can release statically compiled Linux binaries against the kernel & version of glibc. You really only need worry about compatibility-breaking revisions. If you have some time, you can setup everything to cross-compile on the same host. The kernel is backward compatible. glibc is more temperamental.

File paths can be assumed to be Linux Standard Base, if you want to package it with an installer. The more flexible you can be here, the better. I've never heard a customer complain about receiving a tarball of binaries, which I'd recommend offering. I have had customers complain about incorrect assumptions.

Your best bet for a formal package format is probably between DEB (Debian Linux & derivatives, like Ubuntu) and RPM (Red-Hat & derivatives, like Cent-OS). Packages are nice to have, but are just a headache if you don't plan on utilizing the native update manager.

For test & build, I'd personally recommend Gentoo. It's pretty raw, however, so you might want to look into Ubuntu as a distant second choice.

Answer 5

This is an issue for your product management team. Once they have determined that producing a Linux version is a desirable idea (i.e. on a cost-benefit basis), then you will need to find out what distros your customers use or want supported.

In principle you can support any but the more you support the more of a headache it will be, so you want as FEW as possible.

• Support as few OS / architecture combinations as your PM thinks you can get away with
• Deprecate OSs / architectures as soon as you can
• Only take on new ones if premium support customers demand it, or to get big deals, as per your PM's decision.

How hard it is to support them is largely dependent on how complex your product is (esp. dependencies) and how complete its auto-test suite is. Adding more supported OSs ties your hands with respect to library usage, kernel feature usage etc as well as testing, so it's not something you want to be lumbered with long-term.

So in short, it's not a software engineering issue, but a product management one.