What’s the best way to distribute a binary application for Linux?

Question

I just finished porting an application from Windows into Linux.
I have to create an installer of the application.
The application is not open source => I should distribute the application's binaries (executable file, couple .so files, help files and images).

I found several methods to do it:
- RPM and DEB packages;
- installer in .sh files;
- Autopackage.

I don't like first method (RPM and DEB packages) because I don't want to mantain different packages for different Linux distros.

What is the best way to distribute a binary application for Linux?

Answer 1

There is no best way (universally speaking). tar.gz the binaries, that should work.

Answer 2

I've also looked into this at work and I'd have to agree there really isn't a "best way". If your application is being distributed as source then I'd go with the make/configure methods packaged up in a tar.gz. That seems fairly universal in the Linux world.

A good way to get an idea of what to do is to look at larger organziation and see how they distribute their binaries.

Answer 3

There were a lot of good answers (mine included :)) here. Although that is more about binary compatibility (which you do need to worry about).

For installer I would recommend autopackage (we successfully released several versions of our software with it), they did the "installer.sh" part already and more (desktop integration for example).

You have to be careful and test your upgrade scenarios and stuff, depending on how complex you package structure is, but it is pretty neat overall. I fixed few bugs with dependency handling in 1.2.6, so it should be fine.

Answer 4

It's possible to install an RPM on Debian and an APT on RHEL.

If you are going to statically link this program, or dynamically link only with libraries that you will be distributing in the package, then it doesn't much matter how you distribute it. The simplest way is tar.gz and that would work.

OTOH if it is dynamically linked with system libraries, and particularly if it has dependencies on dynamic libraries that will be shared with the client's other applications, then you kind of need to do either RPM, APT, or both.

Answer 5

I tell you an additional possibility, although I am not aware of its status: the Loki installer. Loki was a company doing videogames porting for Linux. It went down in 2002, but the installer is available.

InstallShield is also available for linux. No idea on the status though.

Although many people are proposing you to go with tar.gz, please don't. I assume you want to provide a pleasant experience for the installation procedure to your users. A tar.gz is one of the most low level, low quality, low usability choices you can do. It works everywhere because it does basically nothing, as you know.

The guys at freedesktop.org and the LSB are quite clear on where to put stuff. What you need is a friendly program to do that. Autopackage imho has the numbers (I love it), but despite its age, I haven't seen a single program out there distributed as an autopackage.

Evaluate it carefully, but don't skip the chance of being part of the momentum in favour of it, just because it's not popular. If it works for you, and it works for your users, everything else does not matter.

Answer 6

You may want to try out InstallBuilder. It is crossplatform (runs on Windows, Linux, Mac OS X, Solaris and nearly any other Unix platform out there). It is used by Intel, Motorola, GitHub, MySQL, Nokia/Trolltech and many other companies so you will be in good company :) In addition to binary installers, it can also create cross-distro RPMs and DEB packages.

InstallBuilder is commercial, but we offer free licenses for open source programs and very significant discounts for mISVs or solo-developers, just drop us a line.

Answer 7

Having been through this a couple of times with commercial products, I think the very best answer is to use the native installer for each supported platform. Anything else produces an unpleasant experience for the end-user, and in practice you have to test on every platform you want to support anyway, so it's not really a significant burden to maintain packages for each. The idea that you can create a binary that can "just work" on every platform out there, including some you've never even heard of, just really doesn't work all that well.

My recommendation is that you pick a platform or two to support initially (Red Hat and Ubuntu would be my suggestions) and then let user demand drive the creation of additional installation packages. Perhaps make it known that you're willing to support additional platforms, for a modest fee that covers your time and effort in packaging and testing on that platform. If a platform proves to be very different, you may need to charge more for ongoing support.

Oh, and I cannot overemphasize the value of virtual machines for scenarios like this. You need to build VMs for each platform you support, and perhaps multiple VMs per platform to make it easy to test different configurations.

Answer 8

Create a .tar.bz2 archive with the binary, then publish a feed for it, like this:

<?xml version="1.0" ?>
<interface uri="http://mysite/myprog.xml"
           xmlns="http://zero-install.sourceforge.net/2004/injector/interface"&gt;
  <name>MyProgram</name>
  <summary>what it does</summary>
  <description>A longer description goes here.</description>

  <implementation main='bin/myprog'
                  id="sha1new=THEDIGEST"
                  version='1.0'>
    <archive href='http://mysite/myprogram-1.0.tar.bz2'
             size='10000'/>
  </implementation>
</interface>

Sign it with your GPG key. You can use the tools on 0install.net to calculate the digest and add the GPG signature for you in the correct format.

Then, put it on your web-site at the address in the uri attribute. Any user on most Linux distributions (e.g. Ubuntu, Fedora, Debian, Gentoo, ArchLinux, etc) can then install and run your program with:

0launch http://mysite/myprog.xml

Their system will also check for updates periodically. There are various GUIs for the different desktop environments, but the command-line will work everywhere.

Also look at some of the existing feeds for inspiration.