Distributing binary applications across linux distros

Question

I've written an application which as of yet is not open source and I'd like to distribute the executable across various linux distros. What's the best way to do this, I've looked a little bit at .rpm and .deb packaging but I can't find if that can be used for binaries or not. Ideally I'd like something like the PackageMaker on OS X or a regular installer on windows that will have it automatically copy into /usr/bin. Is that what .rpm and .deb packages are for or do I have to bundle a shell script that will do it automatically?

Answer 1

Here's one option, in the form of a previous SO question:

http://stackoverflow.com/questions/955460/how-do-linux-binary-installers-bin-sh-work

Answer 2

The rpm and deb will store the binaries. You'll need to have a different binaries for each distro or distro variant most likely, just because on different distros things are different like paths.

I recommend starting with the two you have rpm and deb and nail those two distro. Then maybe do a tarball for misc distros have people can extract and directory structure and copy and handle permissions on their own.

Also, for things like deb you can setup a site as a repository. That makes it easy for people to add the repo and get/install the deb in ubuntu very easily. A lot of 3rd party closed source devs do that.

Answer 3

That's what .rpm and .deb files do BUT you have to be sure that the installee distro has the ability to deal with the .rpm and .deb files. If you want something that's sure to run across multiple distros, where you can't be sure that they will have the right package manager, then you pretty much have to resort to the shell script method. I would advise, if you can get away with it, building your binary for both .rpm and .deb - this way, you get most of the distros covered, and you allow users to install in a way they are comfortable and familiar with, and you don't have to try to roll your own installer / uninstaller shell scripts.

Answer 4

RPM and DEB packages are the two primary mechanisms for distributing binary packages in Linux. RPM is used by RedHat and its derivatives (Fedora, CentOS), while DEB is used in Debian and Ubuntu.

The .rpm and .deb files themselves are generally "dumb" archives, and are installed to the correct locations in the filesystem by pre-installed helper applications. You don't have to worry about writing scripts to install files, unless it's a very complicated application which needs special per-system configuration.

The usual patterns I see for distributing binaries are:

• Release a compessed tarball (.tar.gz or .tar.bz2), and let distribution packagers worry about the details. This works well for popular applications, but if it's newly released, nobody will care enough about your application to package it.
• Release as a tarball, plus RPM and/or DEB packages (depending on customer needs). Customers with a supported distribution may install the pre-made package. Anybody who's using an unusual distribution is probably happy to install from a tarball anyway.

Answer 5

You should probably provide a native package for each Linux distribution that you officially support (as you officially support them, you'll be testing on them so doing this should be trivial), and provide a .tar.gz which people can drop in for other ones.

Users can always make their own .rpm etc for some alien distribution which you don't support; but they can't complain to you unless it doesn't work on an officially supported OS.

Which OSs do you officially support? You'll obviously need to test on them all (at the very least, you'll need to pass all your regression test suite on each OS on each release).

This is of course complicated if you support multiple architectures.