Best Cross-Distro Installation Tools for Linux?

swillden asks: "I need to package up some commercial Linux software for multiple distributions (Red Hat Enterprise 3 and 4, Fedora, Novell Desktop, SuSE Professional and Enterprise, Mandrake and Debian), and I'm wondering what tools others have found useful. The software is closed source and needs to be very easy to install. This has been an ongoing problem for commercial software on Linux for some time. Has there been any progress?"

"So far, the options I'm looking into are:

1. Create distribution-specific packages using each distribution's tools. Nice in lots of ways, but a lot of work for ~11 different distributions.
2. Use a commercial cross-distro installer like InstallShield. This is what the previous developers chose.
3. Use one of the open source cross-distro installers, like autopackage or Loki.
4. Write a custom installer.

I really would like to provide distro-specific packages, to make use of the native dependency management solutions and to make the software fit nicely into each system, but implementing, testing and supporting all of those installers may be too costly. It may also exclude any other Linux distributions unnecessarily.

I don't like the current InstallShield installer for multiple reasons. First, it's written in Java which is fine except that it can only run if a JRE is present. Requiring users to install a JRE so they can run the installer to install a (non-Java) product is really annoying. Also, it doesn't really know how to do any proper dependency management, so the developers had to take the approach of installing everything that might be required, often duplicating tools that might already be on the system, and sometimes even creating conflicts. Obviously this approach doesn't integrate with the native package management at all.

The Loki installer has some of the same limitations as InstallShield, but it doesn't require Java and it's very scriptable, so I could probably write code to do the dependency checking and be smarter about what to install.

Autopackage looks very interesting, and I'm going to take all of the docs with me to read on a flight this afternoon. However, I'm concerned that it may be unstable, as it's just reached a 1.0 release.

Finally, I could always just write an installer from scratch, but that may be even more work than creating all the distro-specific packages."

Re:Source?

[walt-sjc]

You can do what Sun, adobe, vmware, and others do. Create a statically linked package with your own installer. You can also release distro specific packages for the common distros, and use the generic binary for all the others. Gives the best of both worlds and doesn't leave out people that prefer obscure distros.

Plain tarball

[yason]

Native packages are better than a custom installer that doesn't integrate with the distribution and doesn't grok dependencies using existing libraries wisely.

My suggestion would be simply to provide a neutral .tar.gz or .tar.bz2 of your application. The tarball would unpack into one directory in which all required files are, including the main executable which could be run straight from that directory. For many, even that would be enough. Gnome and KDE come with built-in archive managers that unpack a tarball somewhere with a single click, and likewise run executable or .sh scripts from Nautilus/Konqueror.

However, the ultimate key here would be to tweak your license to allow re-packing that directory verbatim for redistribution in a Linux distro: if your software is good enough, distribution makers will use their RPM/DEB packing power and merge your software for you for the benefit of themselves and the users of their distribution. I shall remind you that they've already went lengths to provide [debian.org] installation [debian.org] packages [debian.org] for software that doesn't allow being included in their Linux distribution. Compare that to a simple tarball that could be simply repacked by anyone. If your software is good, it would be a service to the community.

Informative?

[Hey, Retard...]

...did you read the summary? It's closed source and commercial. He's not looking for someone to maintain it or for a distro to pick it up.

loki_setup...

[netfunk]

...has been working great for me, for several commercial games like Unreal Tournament 2004. Over the past five years, I've shipped several products using it, both on commercial CDs and downloadable installers.

It _is_ a little quirky in some regards, but once you get it working, it pretty much works everywhere.

If you use it, please use our codefork at http://icculus.org/loki_setup/ [icculus.org], since the Loki Games version died with Loki, and we've put several man months of further development into it since (largely improving things as we ship new software with previously unexpected requirements, a MacOS X port, more archive formats and other enhancements). We're pretty fast to respond when someone has a bug, too.

Otherwise, I'd say give people a tarball and let them sort it out. :) Yes, trying to make distro-specific packages is SO BAD as to make this a better option...even between the various RPM-based distros.

Someone DID mention that it's nice to enable those distros to repackage it in their preferred format, if there's a want, and I think that's an interesting idea as long as you don't rely on people to show up and do it. Gentoo, for instance, provides their own packages for most of the games I've shipped, which will even extract the data off the retail CDs if need be, etc...this empowers Gentoo users to have a consistent experience, but they can still use my loki_setup based installer if they want, as can those without a "real" distro package. This seems to be the least-messy solution at the moment, and it allows the distro maintainers to compete on features while you maintain a single, decent and universal solution yourself.

At least, this works well for me. Your mileage may vary.

--ryan.

Multi-Distro Packaging Tools

[Kvorg]

I am a bit surprized most replies are rather dismissive and not many tools have been suggested to actually solve the problem suggested. If you think of it, there are actually only two wide-spread formats: rpm and deb. And all big distributions have their convoulted ways of installing these two packages even when they are not native to them. If you can cover those two formats with packages for different distributions (Fedora, Madriva, Debian, different Debian-based distros), you can reach many users. Some tools, of course, offer more, including non-linux packages. I can give several examples from the top of my bookmarks:

OpenPKG [openpkg.org] seems like an interesting portable packaging framework. I would be interested to hear from people that have had any exeprience with this.

PkgWrite [ffem.org] is a perl tool that builds debian and rpm packages from a single spec file. GNU/LGLP with liberal relicensing. I suppose it will not save any dependancy issues for you.

EMP [easysw.com] is a commercial solution, offering native packages (debian, redhat, solaris, HPUX etc.) and script-based installs. It costs $99, has a stale web site and I never tried it. But for commercial software, perhaps it can help you.

STOW [ibm.com] is a free perl-based fancy package manager that was pushed by IBM at one time.

But at the end of the day, it is not very difficult to prepare debian and rpm package specs, build chrooted building environemnts and support several distros. Users are really happy when they can apt-get install your software, even if it is binary-only and from your own server. If you don't have nasty kernel dependencies, chrooted building environment might be easier than it seems. And you will only ever be sure in the case of binary distribution if you can build and test your package yourself. And if you have users who want graphical installers, you can always trick Loki to install a standard package. Which should be its default behaivour anywyay, IMHO.