Best Cross-Distro Installation Tools for Linux? 61
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:
- Create distribution-specific packages using each distribution's tools. Nice in lots of ways, but a lot of work for ~11 different distributions.
- Use a commercial cross-distro installer like InstallShield. This is what the previous developers chose.
- Use one of the open source cross-distro installers, like autopackage or Loki.
- Write a custom installer.
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."
Source? (Score:2)
Of course, by far the easiest install method is to have the source. You could just sell the source. Binary i
Re:Source? (Score:2, Insightful)
truer words have yet to be posted on
Re:Source? (Score:2)
I still can't believe he left off both Ubuntu and Gentoo though...lol
Re:Source? (Score:1)
Re:Source? (Score:4, Informative)
Re:Source? (Score:2)
Odds are, most non-standard distros will handle an RPM or a deb or what have you. So, if you just release for the fashionable, major distros, you'll reach 90% of the Linux users, I'll bet.
Yep. I submitted the Ask Slashdot story about three months ago, so a lot has happened between when I posted the question and now. One thing is that the client got a bit smarter about the target market and realized that we could cut back a long way on the list of distros. Basically, we're only doing Red Hat, SuSE and
Re:Source? (Score:2)
Re:Source? (Score:1)
Seriously, I think anybody who buys the software will want to do so with their own setup and everything. You sound like you're suggesting either a LiveCD, or a fully-installable distro. Both have their problems; most notably, you can't use the user's own home directory because it won't have everything you want in exactly the right setup. Secondly, installation of a distro takes time. It may be quicker than Windows but that's not to say you
Re:Source? (Score:2)
If you really need to control that many packages, why not just make your own distro, or package your product with a modified installation for a readily-available distro?
Because this tool is an add-on, an enhancement to their current working environment/system, to make it more secure. Users are not going to want to change their whole system just to get it. They still need to get work done.
seriously... (Score:1, Funny)
oops guess it was just me.
.tgz (Score:2)
KISS.
- Hubert
How about pacman ? (Score:1)
Linux Standard Base... (Score:2)
Re:Linux Standard Base... (Score:2)
Re:Linux Standard Base... (Score:2)
--
Evan
this ... (Score:2)
What everybody else does (Score:2, Redundant)
Unless this is some kind of specialized application that serves a tiny niche market, just puting a source or binary tarball up on the web is usually good enough. If there's enough demand for the application, somebody will pick it up to create and maintain a package for their distro. That's how 99% of the software gets into Gentoo, Red Hat, Debian, etc.
Informative? (Score:3, Informative)
RPM ? (Score:1)
Autopackage! (Score:2)
I've been using Autopackage for all of my installs whenever there's a
Plain tarball (Score:4, Informative)
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.
Re:Plain tarball (Score:2)
A lot of commercial linux software packages are like this. Matlab, Maple, Cplex...
You get to copy the directory wherever you need it and softlink to whatever binary or libs you want.
You may need to tweak an environment variable to make them work, but it works.
Maybe they end up with bigger builds, as they have to include everything in their binary, but at least it works.
Why are there distro-specific packages? (Score:2)
Can someone explain to me why packages are distro-specific? I've installed RPMs from Mandrake, Suse, Red Hat, Fedora Core, etc. on my various Unix boxes - and half the time the distro doesn't match-up. The only problem I've ever seen is that sometimes the icons aren't added to the menus, or something like that. That's not a big deal to me -- I see how it could be for an end user though. But is that all?
Re:Why are there distro-specific packages? (Score:2)
Another issue is prerequisites. One distro might distribute Gtk, another Gtk2, or whatever.
My biggest problem with software installations is that they say something like "Make sure you have version 3 of foolib" but give you no clue how to find that out, or how to update to the version that you need.
Re:Why are there distro-specific packages? (Score:2)
Re:Why are there distro-specific packages? (Score:2)
Glibc versions.
Also, not every distro stores config files in the same manner.
LK
Re:Am I missing something??? (Score:1)
Fairly simple... (Score:4, Interesting)
Well, even though you made it sound almost impossible, all of those distributions except for one use RPM. It really is quite easy to build a RPM file that will work on all of those distributions. You then have to support two things, RPM and DPKG. A properly-written RPM spec file will work on any of those distributions. The hardest part is figuring out the dependencies and specifying them in the spec file, which not limiting anything to specific versions, other than where absolutely necessary.
Having worked with both RPM and ebuilds, I tend to prefer the Loki Setup method for distributing cross-distribution packages. It works on every distribution, and tends to be fairly easy to work with in general. While your package won't be tracked by the distribution's own package menagement, you're talking about creating a commercial software package. It should probably be installing into /opt/$packagename anyway and be fairly self-contained. This seems to work well for commercial software.
loki_setup... (Score:5, Informative)
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.
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.
What about alien? (Score:1)
Homepage [kitenet.net]
So, create a package for your favorite distro and then convert it into all possible formats.
No support for Gentoo, Arch and other systems though, but Gentoo's users are usually advanced enough to figure everything out themselves.
What I don't like about script-based installers
Statically linked compile packaged as RPM. (Score:3, Interesting)
Then put this compile in f.e.
Then wrap this in RPM package - that will do for all RPM based. For Debian do Deb file and you are done with it:
1. Static compile
2. Build RPM from it (simple script)
3. Build Deb from it (simple script)
You can do this on one system, in totally automated manner - just script it.
But also it highly depends on kind of your software and what the installer needs to do:
1. add some symlinks?
2. register as service?
3. add to menu?
4. register MIME type?
Etc. etc.
1. Is quite easy - just contain the symlinks (f.e.
2. This is tricky - you need to issue proper command on post instalation script - this is shitty because different distros have different init/service styles. So here is a lot to do/test.
3. and 4. are now standardized as FreeDesktop, just include *.desktop file along with corresponding icon and *.xml file for MIME config in your package - these files need to go to the proper dir thou. But it is specified by standard and can be overriden by env variable (but usually is not - what for?):
http://www.freedesktop.org/wiki/Standards_2fmenu_
http://www.freedesktop.org/wiki/Standards_2fshare
http://www.freedesktop.org/wiki/Standards_2fshare
When you will use those standards it will work seamlesly on any distro that supports them (all mentioned by you do).
Please use the distribution methods (Score:2)
The packaging methods for each distribution aren't that incredibly hard, but they do make it incredibly easier to install the software.
If you do this, you should really only need to build RPM and DEB (but keep TGZ around for people this doesn't work for, as it is even more trivial).
Where I work we build Debian packages of all sorts of things, simply because it is so easy. We even build Debian packages to "install" a new user on a computer. It ain't hard to maintain after you've done it the first time -
Really (Score:1)
pkgsrc (Score:1)
Take a look at http://pkgsrc.org/ [pkgsrc.org]
Cross-platform solution (Score:2)
zcat mycoolapp.tar.gz | tar xfv -
Package managers are for Windows users.
:-) :-)
Re:Cross-platform solution (Score:2)
But of course, you were not being serious.
Use an "app directory" (Score:3, Interesting)
1. Link the program with "-Wl,--rpath,'$${ORIGIN}'" This makes it look in the same directory as the program itself for shared libraries, as though you set LD_LIBRARY_PATH to that directory.
1a. If your program needs other info, use readlink("/proc/self/exe") to find out where you are. Delete everything after the last slash and put the name of your configuration file there and you have the name of it.
2. Put the executable into a directory named after your app. Copy all the
3. Write some kind of installer that lets the user select where this directory is and unpacks the data there. If you want it to work from the command line the installer can also make a symbolic link from
4. If the user can't stand the fact that the wrong
5. If an end user complains that it does not work, they will probably have an error message telling you exactly the name of the
Multi-Distro Packaging Tools (Score:3, Informative)
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.
Re:Multi-Distro Packaging Tools (Score:2)
I've been using my own forked version of EPM (to allow users to install anywhere, when non-root) for years.
The reason it hasn't been updated in a long time is that it works very well.
Good free cross-platform packaging/installati tool (Score:1)
Native Packages (Score:3, Insightful)
Have you considered contacting people who do 3rd party packages for the commercial* distros you want to target? (For example Dag Wieers** for Red Hat.) I imagine you could negotiate one-off contracts easily and, if your selling your software for real money, relatively inexpensively. This sort of guy would find this a simple task and could build you a high quality package that would probably pay for itself in reduced support costs.
-Peter
* Go with official packagers of non-commercial distros. They don't have the same conflict of interests.
** I know nothing of Dag except that I use his packages and they work great. I surmise that he knows more about Red Hat packages than anyone you're likely to hire.
Autopackage (Score:1)
how about (Score:1)
Klik (Score:1)
http://dot.kde.org/1126867980/ [kde.org]
http://klik.atekon.de/ [atekon.de]
It works fine in Gentoo too.
BitRock (Score:2)
I've not explored it much further than my own basic needs, but it seems to meet the criteria you've listed.
Screenies [bitrock.com]
Comparison to InstallShield. [bitrock.com]
Overview (highlighting some of your concerns) [bitrock.com]
Hope this helps.
You've the cart before the horse. (Score:2)
I have RH Enterprise 3 You have RH enterprise 4. You built an app. Use whatever installer you want, It probably won't work and install on my box. The installer isn't the problem. The problem is that the binaries you are trying to install are completely incompatible with my system!
The illusion in Windows is t
shar & friends (Score:1)