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?

  • I don't know it this fits your case but have a look at it any way: izpack.org
    – Chiron
    Nov 23, 2011 at 18:54
  • @Chiron interesting, but we're trying to not require a JVM be present on the target machine in advance of installing our software.
    – Ian C.
    Nov 23, 2011 at 19:19

6 Answers 6


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.

  • 1
    I've never quite understood things like InstallShield when WiX makes making good installers pretty easy. Maybe that's just me. Nov 24, 2011 at 5:39
  • I can see why it gets chosen, even if I don't agree with the choice. It's less risky to not work on some random configuration. It gets a lot of testing and exposure that a project on sourceforge might not. If an installer breaks, it looks really bad.
    – Tom Kerr
    Nov 24, 2011 at 5:58
  • @BillyONeal Hopefully I will remember WiX the next time I need to do something like that though, thanks!
    – Tom Kerr
    Nov 24, 2011 at 6:01
  • WiX is used for most of the Microsoft installers.... if it's good enough for the Empire I can't see who it'd not be good enough for :) Nov 24, 2011 at 6:02
  • I've worked with InstallShield in the past and not ever really found it worth the money. We're largely self-contained so "deleting" our stuff is just "delete the directory you installed it in to" on both Windows and Linux.
    – Ian C.
    Nov 24, 2011 at 22:39

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.


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.

  • Sane reason? Dependency hell. Seems sane to me. We only test (and only work with) very specific Oracle/Sun JRE versions. :)
    – Ian C.
    Nov 24, 2011 at 22:38
  • 2
    you specify those very specific versions as dependencies within the package managers
    – user7519
    Nov 28, 2011 at 21:38
  • Yeah, what Jarrod said. Managing dependencies is what the Linux packaging systems do. You're not the first one to have a dependency on a specific version of a library. Nov 29, 2011 at 0:01
  • @MikeBaranczak "That's the great thing about Linux - so many different standards to choose from." That was irony, I hope?
    – quant_dev
    Jan 10, 2012 at 14:27

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.

  • A self-contained package, JRE and all, is pretty much the solution we're looking at now. Thanks for confirming we're not crazy (at least when it comes to package formats).
    – Ian C.
    Jan 10, 2012 at 16:58

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.


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.

  • This isn't OSS. No source code is released to the end user. The question is: in what package format should I provide pre-compiled source code?
    – Ian C.
    Jan 10, 2012 at 14:52
  • 1
    Answers are supposed to answer what the question is asking, plain and simple. Your whole answer is based around the premise that "Packaging is goal of package maintainers, not original developers." - For argument's sake let's say that's true: How can you tell OP is not a package maintainer?
    – yannis
    Jan 11, 2012 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.