How do I choose a package format for Linux software distribution?

Question

We have a Java-based application that, to date, we've been distributing as a tarball with instructions for deploying. It's mostly self-contained so deployment is fairly straight-forward:

1. Untar on the disk you'd like it to live on;
2. Make sure Java is in your path and a suitable distro and version;
3. Verify ownership and group on all the files
4. Start up the server processes with our start script

If the user wants to get in to start-on-boot stuff with SysV we have some written instructions and a template init file for it in our tarball.

We'd like to make this installation process a little more seamless; take care of the permissions and the init script deployment. We're also going to start bundling our own JRE with the application so that we're mostly free of external dependencies.

The question we're faced with now is: how do we pick a package format for distribution? Is RPM the standard? Can all package management tools deal with it now? Our clients primarily run RHEL and CentOS, but we do have some using SuSE and even Debian. If we can pick a distro-agnostic format we'd prefer that.

What about a self-extracting shell script? Something akin to how Java is distributed. If we're dependency-free would the self-extracting script be sufficient? What features or conveniences would we lose out on going with the script versus a proper package format meant for use by a package manager?

Answer 1

RPM is more prevalent in the business friendly distros. Debian and Ubuntu both use aptitude. I like aptitude, they both work though. They are not mutually exclusive, though.

Either should be able to verify your basic system facilities are present. You could depend on specific versions of shared libraries, for instance. I've never seen this sort of support in self extracting sorts of tools.

Self extracting is less common. While easier to get a quick and dirty version out the door, you won't have a support system to lean on. Think about how much money people pay for InstallShield. Entire companies make a living doing it. It's unlikely that most organizations would spend the effort to do it right. Suit types tend to think it's free and its a royal pain in the ass.

Answer 2

You should provide a package for each distro/version you want to support. Choose which distros and which of their versions you are going to support and provide the appropriate package (.deb for Debian/Ubuntu, .rpm for RHEL/Fedora, etc.). You might strike it lucky and, for instance, your Debian .deb can be 100% good under Ubuntu, but that doesn't happen all the time (i.e. IIRC, Debian and Ubuntu init scripts are different).

For everyone else, provide a .tar.gz and instructions.

Answer 3

First of all, if you're making a regular Linux package, there's no sane reason to bundle the JRE with it. Just declare a dependency on a JRE (I think this is possible for most of the major distros, somebody correct me if I'm wrong).

RPM is not the standard, but it's one of the main ones. That's the great thing about Linux - so many different standards to choose from. You should start by taking a survey of your users, and see what distros are most popular. You might be able to get away with an RPM for all Redhat-based systems, and a DEB for all Debian-based systems (this includes Ubuntu). Or you might have to sub-divide it further.

Answer 4

I have some experience with packaging applications for Linux (have been a distro maintainer for a while), so let me get this straight to you: you're in trouble no matter what you do. Even an advanced packaging system like RPM does not allow you to create one package and have it work on several distributions. For example, another answer recommends "declare a dependency on JRE". How do you do it? In RPM, you add a requirement

jre >= 1.45

but if the distro called the JRE package not "jre" but "java_runtime_environment", you're out of luck and your package has a broken dependency. Preparing a package which does not hardcode the location of files and your dependencies is far from trivial, and requires relying on the assumption that the distros follow some common standard (which they don't, at least not consistently).

By far the easiest approach for you and your clients is to make a self-contained package. If you want to save space and bandwidth, provide two versions: with and without JRE, with clear instructions how to install the JRE and a link to where a compatible version can be downloaded at Oracle website.

Answer 5

When I started using Arch Linux I have fallen in love in pacman and makepkg apps. It's make building app from sources one of the easiest things in GNU/Linux. It check all dependences and create ready-for-use archive.

Answer 6

You should not see packaging as a priority. Packaging is goal of package maintainers, not original developers.

If you have free HR, you can pick up distributions most vital to you, but not package format!, and provide your software packaged in-house.

Be aware, however, that in that case, you are explicitly required to track all upcoming changes within your chosen distribution and keep them, together with changes to your software, up-to-date. Additionally, downloading precompiled (packaged) software outside of distribution own repository is seen as a security risk. Note, that source-based distributions will still rely upon automatic fetching of source tarball from your site, yet this is done by means of the package manager and is normally check summed.

One of the better choices here is to contact active developer within target distribution of your choice and argument upon assigning him as responsible packager for your software within his distribution. Then, you will only have to mention instructions for installation of your software on specific distribution without any actual binaries, as it will be installed using distribution native package management.

See Play-On-Linux as an example.