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

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.

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.

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

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

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!