Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
I don't know it this fits your case but have a look at it any way: izpack.org –  Chiron Nov 23 '11 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 '11 at 19:19

6 Answers 6

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.

share|improve this answer
    
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 '12 at 16:58

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.

share|improve this answer
    
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 '12 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 Rizos Jan 11 '12 at 8:25

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.

share|improve this answer
    
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 '11 at 22:38
2  
you specify those very specific versions as dependencies within the package managers –  Jarrod Roberson Nov 28 '11 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. –  Mike Baranczak Nov 29 '11 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 '12 at 14:27

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
I've never quite understood things like InstallShield when WiX makes making good installers pretty easy. Maybe that's just me. –  Billy ONeal Nov 24 '11 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 '11 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 '11 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 :) –  Billy ONeal Nov 24 '11 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 '11 at 22:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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