Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Best Cross-Distro Installation Tools for Linux?

Cliff posted more than 9 years ago | from the one-installer-to-bind-them dept.

Software 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:

  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."

cancel ×

61 comments

Sorry! There are no comments related to the filter you selected.

Consolidate Distros (0, Offtopic)

buffoverflow (623685) | more than 9 years ago | (#13577023)

You should look at consolidating what distributions are used in your production environment. Outside of your immediate problem of software installation & package management, there has, (or will be) a myriad of other issues that you'll run into. Upgrades, patches, security issues, and configuration management to name a few. I'd look at trimming your enterprise down to, at the very least, one or two distro's.

Source? (1)

biryokumaru (822262) | more than 9 years ago | (#13577032)

Your best bet would just be to release it as a binary package for multiple distributions. 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. Heck, the Slackware install method is just to tar up the installed program's directory! That'd work for practically anyone!

Of course, by far the easiest install method is to have the source. You could just sell the source. Binary installs don't really drastically reduce the risk of piracy, and theres always the added revenue from suing source-thieves! Just look at how well it's worked out for SCO!

Sorry, that last bit is kinda ranting.

Re:Source? (0, Flamebait)

biryokumaru (822262) | more than 9 years ago | (#13577187)

I know I'm replying to myself, but: perhaps a /. approved list of what distros are important is needed? Let's start:

1 - RedHat
2 - Debian
3 - Slackware
4 - SUSE
5 - Mandriva (Maybe)

Any to add/remove?

Re:Source? (2, Funny)

Shut the fuck up! (572058) | more than 9 years ago | (#13577367)

LOL, it's flamebait because some moderator's favorite obscure hobby distro didn't make your cut.

Re:Source? (1, Insightful)

coaxial (28297) | more than 9 years ago | (#13578034)

LOL, it's flamebait because some moderator's favorite obscure hobby distro didn't make your cut.

truer words have yet to be posted on /.

Re:Source? (0)

Anonymous Coward | more than 9 years ago | (#13580794)

actually it's flamebait because it's a flamebait.

a list of distros leaving out any other distro in the Linux and/or /. arena is flamebait...

no way around that.

Re:Source? (1)

ZephyrXero (750822) | more than 9 years ago | (#13581383)

Do notice how he asks "any to add/remove?" at the end.... this takes it from "flamebait" to not so well informed. The best way would probably be to just take a look at the top 10 distros on DistroWatch.com [distrowatch.com]

I still can't believe he left off both Ubuntu and Gentoo though...lol

Re:Source? (0)

Anonymous Coward | more than 9 years ago | (#13581660)

The best way would probably be to just take a look at the top 10 distros on DistroWatch.com

The top 10 distros on DistroWatch do no represent the top 10 deployed distros. Those numbers, by the way, are page hits not downloads. The submittor does not mention what his software does or who the market is, but a ten bucks says it businesses and/or government not home users and most certainly not hobbiests. I'd say the 5 listed above comprise a super majority of what businesses are using. I'd even go as far as saying that slackware should be removed from the list.

Re:Source? (1)

lengau (817416) | more than 9 years ago | (#13579191)

Ok, what about this? Make RPMs for RedHat, Fedora (latest two; you don't really need to go further back than that), SUSE, and Makndrake/Mandrivia Make a .deb file (should work for ANY Debian-based distro). Make a g-zipped or bz2'd tarball (Slackware, etc.). Perhaps you could make the directory holding these files publicly available. That way, distros like Gentoo (which I use) could add your product to their database. One would simply have to have an account on your server to download the files. Most people use yum/apt-get/emerge/etc. If you required people to log in to your server and to have a product key to enter in (Maybe like a checksum of a file with their info and some other data)

Re:Source? (3, Informative)

walt-sjc (145127) | more than 9 years ago | (#13577306)

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.

Re:Source? (1)

swillden (191260) | more than 9 years ago | (#13579735)

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 Debian as officially "supported" platforms.

Heck, the Slackware install method is just to tar up the installed program's directory!

For a lot of software that works fine. This particular piece of software integrates with a lot of other stuff, though, so it doesn't work. Besides installing some executables and libraries, I also have to install a new display manager, tweak PAM configuration settings and install some browser components. I could, of course, provide a separate configuration script to be run after installing, but this really needs to be a 'double-click this icon to install' sort of thing.

Of course, by far the easiest install method is to have the source. You could just sell the source.

That would be my preference, too. I'm just a hired gun, though, and the client doesn't like the idea. There are some significant open source components in the package, including some that are GPL, so there is some code that must be distributed. Although they have every intention of complying completely with all of the relevant licenses, they insist the part that is theirs and theirs alone must be closed.

In practice I doubt they'd see any trouble with people stealing their code if it were open. This is enterprise software that you generally buy in conjunction with a whole bunch of other pieces and a $500K system integration contract. No one who needs it will steal it. No one who will steal it has any use for it. Seems like a no-brainer.

But it's not my call.

Re:Source? (1)

tonsofpcs (687961) | more than 9 years ago | (#13580673)

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?

Re:Source? (1)

Ciaran_H (579351) | more than 9 years ago | (#13586000)

<sarcasm>Hey, good idea! That's really clever!</sarcasm>

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 can't still spend a lot of time doing it.

Using your own distro in this way would presumably mean you use your own package format - otherwise why not just release in a normal RPM, deb, or whatever? Most distros have (and can use) rpm or apt.

Making a distro takes time in itself, too, and there is absolutely no way you're going to please anybody with one particular distro. Not to mention that if this is a big enterprise thing, they might have to install the program over lots of computers, hence the *need* for the easy installation. Or maybe it's designed to go onto a server, in which case the disadvantages of having to install a distro or use a LiveCD on a working, production server that's already set up should be obvious.

Besides, installing a distro (whether it's your own or not) just for one program is very ego-centric.

Re:Source? (1)

swillden (191260) | more than 9 years ago | (#13588187)

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... (1, Funny)

Anonymous Coward | more than 9 years ago | (#13577134)

anyone read that as "Best Cross-Dressing Installation Tools for Linux" ?

oops guess it was just me.

.tgz (1)

hubertf (124995) | more than 9 years ago | (#13577217)

Make sure it can be extracted everywhere (i.e. don't compile in absolute paths, take some care of what dependencies you need, ...), and call it good.
KISS.

  - Hubert

How about pacman ? (1)

BeesTea (580793) | more than 9 years ago | (#13577226)

Re:How about pacman ? (0)

Anonymous Coward | more than 9 years ago | (#13577317)

I like how it's not distro specific.

Re:How about pacman ? (0)

Anonymous Coward | more than 9 years ago | (#13581159)

Uhh it's not distro specific. Jackass

Re:How about pacman ? (0)

Anonymous Coward | more than 9 years ago | (#13595686)

That's what he said. Dickcheese.

Re:How about pacman ? (0)

Anonymous Coward | more than 9 years ago | (#13615913)

I can't run PacMan or Ms. PacMan on my toaster...

Linux Standard Base... (1)

mengel (13619) | more than 9 years ago | (#13577397)

Going forward, the Linux Standards Base [linuxbase.org] stuff should be the way to go. They provide tools to build software to ensure it is compliant, and tools to check the built software to make sure it adheres to the spec...

Re:Linux Standard Base... (1)

joeljkp (254783) | more than 9 years ago | (#13578008)

I agree. LSB has a framework for creating LSB RPM packages that work on any LSB-compliant system. There's a standard here, folks. Why not use it?

Re:Linux Standard Base... (1)

JabberWokky (19442) | more than 9 years ago | (#13578848)

Yup. Even non RPM based installs like debian based Kubuntu has rpm installed as part of the base install... it's the standard package format, and for commercial software -- where you can control, include or link your dependancies -- it's great.

--
Evan

What everybody else does (1, Redundant)

Eil (82413) | more than 9 years ago | (#13577644)


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? (3, Informative)

Hey, Retard... (915400) | more than 9 years ago | (#13578355)

...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.

RPM ? (1)

tuxpert (512567) | more than 9 years ago | (#13577791)

RPM is the default package manager for RedHat, Fedora, SuSE and Mandarake. You'll still need to create distribution specific RPM's but that's mainly changes to the SPEC file and rebuilding. IIRC, RPM's can be converted deb's as well, do Debian is taken care of with one additional step.

Autopackage (0)

Anonymous Coward | more than 9 years ago | (#13577804)

There is Autopackage [autopackage.org] . Never used it but it looks like it'd suite your needs.

From Wikipedia [wikipedia.org] :
Autopackage is a relatively new package management system for GNU/Linux, intended to be usable under all distributions. Unlike the RPM and Deb package formats, Autopackage checks for the presence of dependencies on the actual system, rather than querying a database of package information. Although this reduces compatibility issues with different package naming conventions, it does mean that Autopackage is slower than distributions' native formats. Autopackage packages are actually executable bash scripts, so that they can be installed simply by running them. Autopackage is intended to be used for installing non-core applications such as word processors, web browsers, and games, rather than core libraries and applications such as shells. For core applications and libraries, the distribution's native package manager is recommended for speed and compatibility reasons. Non-core libraries are something of a thorny issue, on the one hand packaging them allows installation on a greater range of systems, on the other hand there can be issues with conflicts when native packages are installed that depends on libraries that have been installed by autopackage. Autopackage differs from other executable installer systems for GNU/Linux such as Oblisk and the Loki installer in that Autopackage is specially designed to be compatible with as many distributions as possible. Autopackage uses APbuild to strip bogus dependencies, "cross-compile" to make C++ programs compatible with different versions of g++, and fix GLIBC version symbols, among other things. Programs must also be relocatable, meaning they can be installed into any location without needing to be recompiled.

Autopackage! (1)

ZephyrXero (750822) | more than 9 years ago | (#13581421)

I second the suggestion of Autopackage. It's easily the best way to install high level software on Linux. Virtually every distro works with it, and it's easy enough for anyone to use with out having to read a bunch of docs first.

I've been using Autopackage for all of my installs whenever there's a .package available and it works great! I've used it with both Ubuntu, Fedora and Gentoo so far personally.

Plain tarball (3, Informative)

yason (249474) | more than 9 years ago | (#13578246)

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 (1)

gatzke (2977) | more than 9 years ago | (#13581901)


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? (1)

MobyDisk (75490) | more than 9 years ago | (#13578248)

What is the difference between a Suse RPM and a Red Hat RPM and a Fedora Core RPM?

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? (1)

Intron (870560) | more than 9 years ago | (#13578545)

The files might be the same, but the directory structures used to be very different, so they needed different RPMs. That isn't as much a problem anymore, though there are still differences.

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? (1)

ZephyrXero (750822) | more than 9 years ago | (#13581483)

This is why most newer distros are using other package managers these days. Debian's apt and Gentoo's Portage do alot more dependency checking and just seem to work much better in general. I've heard good things about Pacman too, but never used it. RPM is slowly but surely going to die out unless they completely revamp how it works. If you can, I'd suggest just looking for a .package [autopackage.org] as they generally work with almost any distro with very little effort. ;)

Re:Why are there distro-specific packages? (1)

Lord Kano (13027) | more than 9 years ago | (#13588750)

Can someone explain to me why packages are distro-specific?

Glibc versions.

Also, not every distro stores config files in the same manner.

LK

Am I missing something??? (0)

Anonymous Coward | more than 9 years ago | (#13578297)

Red Hat Enterprise 3 and 4, Fedora, Novell Desktop, SuSE Professional and Enterprise and Mandrake all use the same installer! RPM! It seems that you should build a platform agnostic (minimize the non-standard dependencies and static link/include the ones that you can't avoid) RPM and satisfy 88% of your needs. The remaining 22% could be handled by a .deb or, better yet, source.tar.gz.

Indeed Debian can even handle RPMs via the alien program so it seems like a single RPM could solve your dilemma. Am I missing something?

Re:Am I missing something??? (1)

imadoofus (233751) | more than 9 years ago | (#13578472)

Doing this can take care of 110% of your needs!

Fairly simple... (3, Interesting)

wolf31o2 (778801) | more than 9 years ago | (#13578385)

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... (4, Informative)

netfunk (32040) | more than 9 years ago | (#13578389)

...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.

What about alien? (1)

zlogic (892404) | more than 9 years ago | (#13578501)

"Alien is a computer program that converts between different Linux package distribution file formats. It supports conversion between Linux Standard Base, RPM, deb, Stampede (.slp) and Slackware (tgz) packages." (From wikipedia)
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 is that such programs don't appear in apt-get or rpm -e, they also don't handle dependencies in a nice way (e.g. automatically downloading them).
So, what I think is best is creating .RPM, .DEB and .TGZ packages, and a script-based installer like nVidia's drivers for users who don't like extracting TGZ but don't have a .RPM or .DEB -capable distro.

Statically linked compile packaged as RPM. (2, Interesting)

kosmosik (654958) | more than 9 years ago | (#13578674)

Well compile it statically as every lib used by this app will be compiled in so you won't need to track any dependencies.

Then put this compile in f.e. /opt/myapp.

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. /opt/myapp/bin/myapp -> /usr/bin/myapp) in package and they will get installed.

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_2 dspec [freedesktop.org]
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec [freedesktop.org]
http://www.freedesktop.org/wiki/Standards_2fshared _2dmime_2dinfo_2dspec [freedesktop.org]

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 (1)

Karora (214807) | more than 9 years ago | (#13578824)

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 - if it was, then a lot of Debian developers would find it difficult to do as volunteers.

Really (1)

PunkOfLinux (870955) | more than 9 years ago | (#13579019)

Go with autopackage -- it seems to be pretty easy to use, and it runs on everything.

pkgsrc (1)

dizzy tunez (89390) | more than 9 years ago | (#13579034)

Maybe pkgsrc would be the solution?
Take a look at http://pkgsrc.org/ [pkgsrc.org]

Cross-platform solution (1)

spaceyhackerlady (462530) | more than 9 years ago | (#13579620)

cd /usr/local
zcat mycoolapp.tar.gz | tar xfv -

Package managers are for Windows users.

:-) :-)

Re:Cross-platform solution (1)

Dan Farina (711066) | more than 9 years ago | (#13602306)

And people who like to actually remove software now and then. Without holding onto their old configured makefiles.

But of course, you were not being serious.

Use an "app directory" (2, Interesting)

spitzak (4019) | more than 9 years ago | (#13579748)

This is what we do. I'm not claiming it's perfect, but our software has been installed on several Linux distributions we have never even seen, with no problems.

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 .so files that you think the user will not have from /usr/lib into this same directory. In our case this is libtcl8.4.so and libfreetype.so.6 and the libraries used by the Intel C compiler (libcxaguard.so.5, libimf.so, libsvml.so). Put all the configuration files in there as well. Make sure it works without LD_LIBRARY_PATH set (use ldd on the executable to see what it is using).

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 /usr/bin to the executable. In our case we used a self-extracting zip file, where the executable is tacked onto the start and normal libzip is used to extract it (we statically link libz and stuff so we are sure it works).

4. If the user can't stand the fact that the wrong .so file is used, they can go in the app directory and rename the local copy so it is not found and their system one is found.

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 .so file that is missing. Add that to your future distributions, and give them a copy to put in their app directory.

Multi-Distro Packaging Tools (2, Informative)

Kvorg (21076) | more than 9 years ago | (#13579955)

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.

Re:Multi-Distro Packaging Tools (1)

HuguesT (84078) | more than 9 years ago | (#13589824)

EPM [easysw.com] , the Easy Package Manager, is Free Software. The support (following best FSF practice) is for pay, $99 per year.

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.

Klik (1)

dcapel (913969) | more than 9 years ago | (#13580091)

Just a few moments ago, I was reading about klik: http://dot.kde.org/1126867980/ [kde.org]

It sound just like what you are looking for :)

Good free cross-platform packaging/installati tool (1)

svr0002 (536813) | more than 9 years ago | (#13580368)

We use EPM (http://www.easysw.com/epm/ [easysw.com] ) from Easy Software. Free, cross platform/distro, buy support if you want to. Works just fine.

Native Packages (2, Insightful)

pete-classic (75983) | more than 9 years ago | (#13581486)

If you are going to ask people to pay for your software it would be in your best interest to provide them with native packages. I'm sure your other three options sound tempting but I think it's worth your while to avoid the "pain in the ass to install" or "broke when I upgraded" or "broke my upgrade" or "can't get it to work on the server running the other program we need that uses a non-native install" stigmas.

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 (1)

Sodki (621717) | more than 9 years ago | (#13581720)

Go with Autopackage. It was created for this sort of thing.

Has there been any progress? (0)

Anonymous Coward | more than 9 years ago | (#13581960)

Yes.

Look here:

http://dot.kde.org/1126867980/ [kde.org]

how about (1)

FudRucker (866063) | more than 9 years ago | (#13586195)

look at mozilla.org at thunderbird email client for Linux as an example, you dont actually run any installer, just unpack a tar.gz file and open the directory and run the executable, make whatever symlinks, menu or desktop icons/shortcuts needed

Klik (1)

FAB10 (767615) | more than 9 years ago | (#13586711)

You could try klik if all the systems have KDE installed, it's a MAC-like system for application distribution/installation:

http://dot.kde.org/1126867980/ [kde.org]
http://klik.atekon.de/ [atekon.de]

It works fine in Gentoo too.

Cross-distro? Are you nuts? (0, Offtopic)

suitepotato (863945) | more than 9 years ago | (#13587510)

This would be like... something on the order of Microsoft Foundation Classes being promulgated for the larger framework outside of the kernel. The deuce you say!

Seriously, no, nothing really and truly fits the bill and putting the source code to the various distro package repository working groups is probably best in addition to actually hosting the source for anyone who wants it.

Just remember to start from the basics that have the widest applicability between distros. The lack of compatibility is a reflection of the wrongness of the idea that all you need is a kernel and some standards and the rest falls into place. Linux is not Windows when it comes to this sort of thing and this is one of the places it really needs to be more like it. Fark, there was a time when there were umpteen installation systems for Win apps and that didn't work for one platform never mind a scattered one like Linux.

You've the cart before the horse. (1)

Allnighterking (74212) | more than 9 years ago | (#13602268)

The problem isn't a universal installer. In fact the installation phase is the least of your problems. 99% of what people are trying to solve, is, IMHO a problem with square pegs and round holes.

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 that the installer solves the problem. I mean one CD one set of binaries right? Wrong. Look on that CD it has different sets of binaries for every version of windows they claim to support. (98 2000 ME XP NT etc etc etc etc) All they are doing is presenting a single interface to the user, not presenting a single set of binaries. Now that part ... a single interface. A tarball and a bash script is all I need. The rest is gui.

shar & friends (1)

halleluja (715870) | more than 9 years ago | (#13611870)

Use shar to package files as shell script and prepend a custom install script; works like a charm.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?