Installing Everywhere?

PlainBlack queries: "Our company has been developing an open source project for a couple years now that has gotten pretty popular. The one thing we haven't yet figured out how to do well is packaging. It seems like every operating system has it's own standards for packaging, and installers, and for each OS we support, we end up adding a lot of time to our packaging process. So my question is, what do all of you do to package your apps? Do you just release source tarballs? Do you manually package your RPMs, EXEs, DEBs, DMGs, BINs, PKGs, [and MSIs] by hand? Do you have an automated build process that creates all the packages? If so, how does it work? Is it available for other developers to use?" There are tons of installers listed on SourceForge, but which one allows the creation of OS packages without too much hassle? Duplicating work, especially software installation procedures, across all supported OSes, is time consuming. Is there an easier way?

Comments

Use industry solutions

[Anonymous Coward]

InstallShield and Wise are perhaps the best-known products for deployment management. Use the professional products, they might add a little to the bottom line of the products, but will save hours of support time from angry users calling and asking where they can get the missing library.

Or switch to Java/.NET, lots of issues related to DLL Hell have been solved there.

self-extraction

[aminorex]

A self-extracting installer can be produced for every platform. Unless your application needs to become a part of the platform, it should be isolable, and installation should be as simple as expanding a self-expanding archive. Such archives can be produced for every popular platform. Using dependency=tracking packages is not feasible if you require that your installation model be cross-platform, but that's really no big loss: by including all of the dependencies for each application within the applications own directory, dependency conflicts are effectively eliminated.

Or you can do it all in Java, and it doesn't matter what your platform is. Webstart rocks these days.

Re:self-extraction

[moncyb]

Please no self extractors. Especially in Linux. In my experience, 90% of the Linux ones never work. I especially love the ones who say "can't install -- need at least version 2.2.x of GNU libc" when I have 2.3.x (which is backwards compatible). Luckily they're usually bash scripts in front of a tarball, so I can just find the start of the archive and untar it. Even though I can do it, it sucks bigtime.

I also like to know what the package is going to do and what files it will create before it installs. You can't do that with self extractors. Self extractors are a PITA.

Your suggestion of including the dependencies (at least the less common ones) with the package is a good idea though.

Re:self-extraction

[jmb-d]

Or you can do it all in Java, and it doesn't matter what your platform is. Webstart rocks these days.

...unless you're on a slow dialup connection and are not in control of the development effort.

It recently took ~45 minutes to fire up (via Webstart) a Java application that decided it needed the latest version. According to a co-worker who uses that application, "the developers are constantly tweaking that app".

Pardon my Naievity...

[NanoGator]

... but why do installs need to happen in a lot of cases? I mean, there are some situations that it's a no-brainer. But why can't a large majority of apps out there just run straight out of what directory they are in?

As I mentioned in the subject, I'm a little naieve here. The concept of 'installing' software has always baffled me. I think I'm just missing an important bit of info here.

Re:Pardon my Naievity...

[darkpurpleblob]

why do installs need to happen in a lot of cases?

Right, when you are installing a complex server side piece of software, using an installer is a no brainer. But for simple apps, installers (on Windows at least) let users ignore where it gets installed to, and create shortcuts for launching it from the Start menu/Desktop/Quicklaunch bar. Next --> Next --> Next --> Finish. Simple. If you weren't using an installer, the process would be extract app to some directory, go to directory, and create shortcuts for the app. Now, you may not have troubles doing this, but there are plenty of non-technical users out there that will.

Re:Pardon my Naievity...

[NanoGator]

"Now, you may not have troubles doing this, but there are plenty of non-technical users out there that will. "

Is that pretty much the reason? So it provides an uninstall path too?

I can see that. Little surprised I got modded as overrated, though. Then again, I come from the Windows world. Installing apps = bigger registry. Bigger registry = slower Windows. Slower Windows = reinstall once a year. Those of us that'd like to put that reinstall off like apps that don't touch the registry, even to install.

Oh, to answer my own question, I chewed on this a bit myself and came up with an embarrasingly simple answer: file extensions. A lot of apps have some sort of project file to open. For that to work, you need to set up it's unique extension to run that particular app.

Re:Pardon my Naievity...

[spitzak]

So it sounds like the main problem is adding links to the start menu.

Why not have the program offer to do this when it is first run? The user downloads an executable and it appears on their desktop. They then double-click it and it runs. It examines the start menu and if no link is there it pops up a question asking if you wan to install it. The user can say yes/no/later. If they say yes it adds the startup item.

Re:Pardon my Naievity...

[bigsteve@dstc]

I'll pardon your naivety, but not your spelling :-)

Re:Pardon my Naievity...

[usotsuki]

I always spell it "naïveté".

And that's not because I like being a grenouille, because frankly, I don't like the grenouilles.

-uso.

Don't Install!

[zulux]

Almost every platform has an X-Windows 'client' - just run around and install the X-Windows client and get it to point to one Application server. Then you just upgrade the Applciation Server and presto - you're done.

Applications that need to print ar a pain, amung other problems, but if you can get away with it then this works well.

Re:Don't Install!

[jo42]

Eh, what the fork are ye babbling about?

Re:Don't Install!

[usotsuki]

Yes, even Windows, DOS and the MacOS have X servers. I like your point - ssh into the system, launch the app, run it remotely over X Window - hell, that would save a lot of aggravation if everything was run that way - but might make some new company out to be a borg, borg, borg...

-uso.

JAR

[trompete]

I've seen .JAR files (Java) that worked on every platform. I think it was part of SourceForge's JEdit project.

Re:JAR

[Scottm87]

The concept behind them is fairly simple. Basically, you create a self-executing jar which executes java code which it contains to extract itself. It is basically like a executable zip file.

Re:Speaking of Packaging.

[adamshelley]

haha. awesome. thanks for that: now no one else has to.

Of course, by replying to this I'm bringing on a few more i'm sure.

static binary

[denthijs]

i think the easiest thing to do, is do it the 'rollyourown' way,
just make a big binary file that on executes checks its enviroment;
what is my $PATH?, where is my ld.so configured?, am i root?, etc
then just extract your parts in the correct directories
if the software is good enough normally the community itself will mail you with packaging offers for various platforms

Try Ant

[adamy]

Seems that there are two ways people go on this.

1) Put everything into one huge directory. Create all the symlinks and path extensions etc.

2) Out things in the 'correct' directories (/usr/bin for exectuables, /ur/lib for libraries etc).

THe first ie easier to install and for the user to find and wipe out. The second is easier for users that have many apps on theri system (especially if config files for $app are in /etc/$app).

On windows you don't really have that option, but you don't tend to run as many apps from the command line (which is the real reason there is a space in c:\Program Files\) And the tendancy is to put config stuff in the registry.

Check out Ant. As part of a build process it knows about jars, rpms , cabs and zips. I'll bet there is a taks out there for creating .debs as well. I realize this is a "hand rolled solution" but it is probably the most extansible.

Only 2 options.

[BrookHarty]

I rather download my win32 programs in .zip format, and unix files in .tar.bz. Thats it, installers are overkill.

Why do developers force the users to put applications when they don't know the system. How many windows apps install in C: with your program files is on D: or another partition. Stop forcing the users, and make your programs run out of its own directory.

Just look at how many people only download mozilla in the .zip/.gz formats, so they don't have to mess with the installers? Lots.

And to top it off, no installer means no extra work get the program out the door. And makes a certain level of support, if they cant unzip the file, they need to pay for your premium support package.

Final thought, no install script means registry or other files I have to backup on a reinstall. Just give me a directory with .conf/.ini files I can backup. Makes it easy for me to restore the system. Having to restore the entire OS for an application is shitty design. Bad enough in windows I have to take registry snapshots to save the registry keys. In unix symlinks pointing to symlinks just to point to a .conf file in another directory. I think some developers have been sitting in front of their computer too long to know what the real environment of a production system is...

Re:Only 2 options.

[AnamanFan]

I don't want to say your reasons are invalid, because they are valid, but you're forgetting the non-l33t users.

When you're releasing to the general public, you have to make it easy as sin to install. Though all of us here can think unziping a zip/gz file and placing its contents to its home is easy, this goes way beyond 'normal' users. Installers are needed for the general public.

This is a proplem with the OSS community; in order to be sucessful and adopted, the general public needs to be able to use the software. The closest that comes into my mind is Mozzila, but they are no where near being completly normal-user-friendly.

However, I do belive there is a way to make an installer that can easilly pop between 'easy' and 'expert' modes, even with out a concious seperation. I don't think it hurts to but in a 'chouse your install location' diolge box for instance.

It's a matter of being smart and understanding your target audience. Not having a gz file of PHP is perfectly alright. Having a gz file for a end-user web browser is not.

Re:Only 2 options.

[benjamindees]

In unix symlinks pointing to symlinks just to point to a .conf file in another directory.

I used to think this was stupid, too; like SCO's hellish directory structure. It's invaluable, though, if you find you need to configure a package on a read-only filesystem, like Knoppix, for instance.

Re:Only 2 options.

[secolactico]

Why do developers force the users to put applications when they don't know the system. How many windows apps install in C: with your program files is on D: or another partition. Stop forcing the users, and make your programs run out of its own directory.

That's an easy one. A lot of users aren't even aware of their Program Files directory. Poorly designed installers will default to "c:\program files", but I believe there's a registry key that says where your program files is (after all, the name varies also with the language).

Most of the time, installers will default to this location but give you the choice to change the path. Also, it gives a good oportunity to display license agreements.

But your point is valid, every app should run from it's own directory. It really bugs me when apps *have* to install something in you system32 dir or somesuch, specially when your system partition is nearly full.

Re:Only 2 options.

[darkpurpleblob]

Just look at how many people only download mozilla in the .zip/.gz formats, so they don't have to mess with the installers? Lots.

What about the people who download it in .exe format, so they don't need to mess with extracting it and setting up shortcuts in the Start menu? (Or because they don't know how to?) I'm sure there are lots of them too.

And to top it off, no installer means no extra work get the program out the door. And makes a certain level of support, if they cant unzip the file, they need to pay for your premium support package.

Or they simply don't pay you for support and they find some other program that does have an installer.

Re:Only 2 options.

[N8w8]

If I need an app, and there's a Debian package available, I use that. Later on I can remove the package with a simple apt-get command.
If there isn't a deb available, and I get the tarball and do the "./configure && make install" thingy, the files end up everywhere in /usr/local, which makes it harder to remove.

I agree with you that if the packaging isn't done 100% correctly (as often happens with Windows apps), you indeed might get bald because of pulling out your own hair. Fortunately, the obvious and simple workaround for that is shaving your head. Works for me.

Re:Only 2 options.

[tsvk]

Why do developers force the users to put applications when they don't know the system. How many windows apps install in C: with your program files is on D: or another partition. Stop forcing the users, and make your programs run out of its own directory.

That's an easy one. A lot of users aren't even aware of their Program Files directory. Poorly designed installers will default to "c:\program files", but I believe there's a registry key that says where your program files is (after all, the name varies also with the language).

The folder is at least present in an environment variable: %ProgramFiles% (check it out along with all other variables for example by typing 'set' in a command prompt). It's set probably in the registry, too somewhere.

Re:Only 2 options.

[robin]

If you don't like things being messy in /usr/local/ try stow -- it helps you maintain a tree of symlinks to individual package trees. So /usr/local/bin would be filled with symlinks pointing to /usr/local/stow/package-0.9/bin/program and so on. You can add a single directory to your PATH and run the "default" versions of things, or specify explicitly a particular version.

It is also handy for keeping old versions around in case you need to roll back upgrades.

It's kind of hard to describe, the link above should make things clearer. Or just try it.

Re:Only 2 options.

[usotsuki]

The answer is ZIP self-extractors!

InfoZip (and their WiZ project), PKWARE, Nico Mak (WinZip) all make them, and there are self-extractors for all the various Unices as well. Plus graphical ZIP extractors aren't hard to find either.

-uso.

Easy Package Manager

[grotgrot]

Easy Package Manager (from the same people who brought you CUPS) solves all your UNIX needs. It can produce a package that is in the native format of each platform, in addition to having its own self extracting GUI installer.

InnoSetup on Windows is really good, although some people also swear by NSIS (NullSoft Installer (brought to you by the same people who did winamp.

Re:Easy Package Manager

[mehu]

Yes. As Sr. Release Engineer at a major security software company, I used EPM to create all the UNIX packages, which meant Tru64, AIX, HPUX, & Linux (RPM). Beat the hell out of doing everything 4 times. EPM rules. And fortunately, someone else was in charge of the Windows installers, so I didn't have to worry about those. :>

Installing Everywhere?

[darkpurpleblob]

Installing Everywhere? Use InstallAnywhere, a cross platform Java installer. Nasty licensing and pricey though.

Re:Installing Everywhere?

[smelroy]

InstallAnywhere has worked pretty well for us. We are using the old version 4.5, standard edition. They are up to 5.5 now I think. If we weren't distributing a Java application I am not sure how worth it IA is though. You have the overhead of a JRE in the installer. They do have a free version BTW. It is called Now!.
The other thing is Linux users like to just untar their stuff and run it. Installers can be a waste of time. The thing is, it is better to waste the time of a few savy people than to make it difficult for others to get going if you have a non server application.

Easy

[Anonymous Coward]

In your 'Package Explorer' view, just click on your jardesc and choose 'Create JAR'. If you release often, you can make yourself a script to automatically put the results online or send by email, etc.

Not open source but...

[cornice]

I'm sure there is a need for a mature, full featured, easy to use, cross platform installer that's open source. Unfortunately I don't know of one nor am I capable of creating one right now - although it's a good idea. Most of what you found in your search are installers for MySQL, Apache, PHP, etc. What I do know is that InstallAnywhere installers always seem to work on whatever platform I'm using (Win, Lin, Mac). They have an unlimited evaluation period and I'm sure you could get some nice extras by paying some money. I also suggest looking at AutoIt which is free (soon to be open source). It can be real nice when working around quirks in Windows.

To install or not to install

[Kvorg]

If you really feel you need to do something original, you could as well not install at all, or use Zero Install (Covered on Sweetcode recently).

But in general (if you are not running under an interpreter or emulation layer) all applications should install in a compatible way on any system, even when that is quite different from a system to another. So on Unix install in a reloctable directory tree with /usr/local/ as default (bin/, lib/, man/ etc/ etc.), and provide packages for distributions.

The usual way to do that is to prepare make targets (such as "make debian" and "make redhat" and use the defualt packaging system everywhere. Not that I would know how to do that on Windows...

You will have to distribute sources or build it yourself on each platform, and that represents the real problem. Getting the make targets right is the easy part - many free software applications contain that, and all distributions come with nice examples.

(Besides, Debian's Package Builder makes for an excellent multiarchitecture (11!) compilation cluster and should be a good reason to provide and mantain debian packages.)

Re:To install or not to install

[jmccay]

I think you can do make type targets with the MSYS platform which is a part of the MinGW projects. People have successfully used it with wxWindows (an awesome crossplatform platform {it is more than just a library}), and I plan on compiling with it this afternoon, or tonight.

home growns system

[josepha48]

we have ...

If you support several platforms then you have to package differently for each and maintain for each. If you have a home grown system like us we have one system that works on all the platforms we support and it is easier to deal with. Basically it is a set of bourne shell scripts to untar our stuff from cd to disk and setup a few things on the system like in teh /etc dir.

Re:Speaking of Packaging.

[darkpurpleblob]

Can anyone offer some input on how a programmer can redistrubute updated code to the users.

You could use update software. PowerUpdate, Update Server, RTPatch, and vBuild are a few commercial offerings.

portability before packaging

[hubertf]

Speaking as someone who worked a lot on NetBSD's 3rd party software system, pkgsrc, which today has ~4.000 pkgs:

It's less important for software to come "pre-packages" properly, but that both the code and the build infrastructure are written with portability in mind in the first stop.

* Make sure your software compiles on non-i386 non-Linux (don't #include , don't assume /proc is the same on all Systems, don't use clone(2), etc).
* Make sure it can be relocated (configure --prefix=/foo working properly if you have to use GNU autoconf).
* Don't assume everyone uses GNU make
* Don't assume /bin/sh == Bash
* Don't depend on obscure non-easy to install software components (that again may not be present on non-i386 non-Linux - think Java!).

If that is done, your software can be added to any 3rd party package systems easily.

- Hubert

Re:portability before packaging

[Anonymous Coward]

HP is giving free accounts to test their hardware/software in it's testdrive program.
This permits you to test software on linux, *bsd, Tru64, HP-UX, and OpenVms systems.
Harware available is pa-risc64, alpha, ia32 and ia64.

I also found a new project that could be interesting to replace autoconf :
http://sf.net/projects/premk

Hope this stuff will help :)

distro's job

[Anonymous Coward]

it's the distro's job to do the binary packaging.

You should focus on the source code, and work with red hat, debian, gentoo, *bsd, etc to make sure your code is easy enough to compile and for them to package.

Some advice for Unix systems

[reynaert]

On Unix, I would only create binary packages if:

• your program has a particular appeal to newbies and it is not included with most distributions,
• the build procedure is unusually complex, or
• your program takes ridiculously long to build.

I think most experienced Unix people are comfortable with building from source, and many people just don't trust third-party packages, as they're often badly packaged or out of date.

If you decide to do it anyway, one tool that can help you is checkinstall. It monitors the standard make install process and can create several kinds of packages. I doubt the quality of the generated packages is very good though, and you still have to take in account that different distributions have different policies.

Also, make sure you don't waste effort creating packages for distributions that already include your program. You mention DEBs, but whatever your program is, I'm pretty sure Debian already includes it :)

Makeself is nice for Unix.

[bruthasj]

The Loki Installer stuff is pretty sweet: http://www.megastep.org/makeself/

Never used it for windows.

Re:Makeself is nice for Unix.

[MEGASTeP]

Well, the Loki Installer stuff (of which Makeself is a small part) does not have a Windows version, at least just not yet... Though the latest version is portable to most Unix systems, including OSX.

hmmmm....

[XO]

Obvious idea seems to me, if it's a massively multiplatform thing, that runs on all sorts of different things from Windows to *nixes to every other thing under the sun:

Include a script / batch file / EXE / binary / whatever along with a compressed archive inside the main archive:

ie:

CoolSoftware-1.0.zip

contains:

package.tar.bz2
setup.exe (windows)
setup.sh (unix)
INSTALL.EXE (vms) ... so on so forth for each OS ...

then your install program figures out what the heck to do with the archived files, depending on what the host system is.

Seems obvious to me. Am I wrong?

Other than source, release Slackware packages.

[Rev. Null]

If you must release binaries, do it in the Slackware format. They're just tarballs with install scripts. Everyone's got tar.

Re:Speaking of Packaging.

[moncyb]

Are you a programmer? Simple HTTP isn't that hard. Anyway, just about every language has some sort of HTTP library. I believe both Python and Perl's standard distribution comes with one. There is one for C at w3.org. I serously doubt even Microsoft wouldn't include some sort of library to facilitate downloading with HTTP--they merged an entire web browser into their operating system after all.

Unified package system?

[siveliini]

Would it be too hard to find a standard way to form installation packages? A meta package which would hold the needed information. Then you could write an OS specific installer which installs the meta packages or converters to convert meta packages to OS specific packages/installers.

I know there are some hard parts to solve like lack of similiar file structure, different executable formats and lack of unified scripting language.. But could this be possible?

Perl can be used on almost any system for meta scripts, file system could be defined using a meta language like $programs.$appname.$executables which would translate to C:/Program files/AppName or /usr/local/bin according to OS specific package handlers.. Well.. Executables should be provided separately unless we are packaging source-only with compilation instructions..

I'm surely not the best man to speculate this - is there anyone who could give a good view on the problems of this kind of approach? It would surely make life a lot easier for the end users if they could install any package with their favourite installer app.. Easy wizard installers for beginners and more complicated but more versatile installers for advanced users..

Re:Easy, plus A-A-P complete solution, overviews

[Kvorg]

Hey, Easy Package Manager looks great. It's comparative table of existing installer/packager formats is a good answer to this topic. And it even has a FLTK graphical frontend (I love FLTK for its speed, lack of bloat and beautul API). However, it does not support Windows, which is raher logical from the design point of view.

But I found a nice list of existing packaging tools at the A-A-P which "makes it easy to locate, download, build and install software. It also supports browsing source code, developing programs, managing different versions and distribution of software and documentation." Definitely worth a look!

Re:I hate to break this to you but..

[Anonymous Coward]

Actually that was one version, its just using Genetic algorithms to evolve

Hmm

[thejackol]

Release a zip and a tar.gz, and let them figure the rest out!

Why "install" at all.

[baadfood]

I am a great fan of software that you simply extract into a directory, and run from there. Ideally, any further installation would be done by the application itself when it is run and detects that its being run for the first time.

Re:Why "install" at all.

[Idealius]

I think this is the best idea yet.

tarballs

[panda]

I have used GNU autotools on the projects that I've worked, whether my own or started by someone else.

There's a feature of GNU autotools that lets you make dist to roll a tarball of your package. Very easy, very neat and you don't have to worry about installers when you send source code.

A-A-P

[digitect]

Vim's author, Bram Moolenaar, is working on a multi-platform software installer/maintainer called AAP. It's still young, but might be what the OP is looking for.

Re:Speaking of Packaging.

[Anonymous Coward]

Too right. Use Common Lisp.

Install Anywhere

[Anonymous Coward]

Check out Install Anywhere. Builds cross-platform installs and web-based installs. There's a free version for non-commercial products as well. Very nice tool.

if you can get java installed

[Anonymous Coward]

sun must hire you people to spam this crap on here. ever try installing java on netbsd or linux or debian? or freebsd? and then trying to do something like install netscape and/or openoffice.org as well? and have version incompatibility problems?