Slashdot Mirror
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?
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.
-I like my women like I like my tea: green-
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,
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
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
Open Source Identity Management: FreeIPA.org
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.
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).
/usr/local/ as default (bin/, lib/, man/ etc/ etc.), and provide packages for distributions.
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
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.)
-Kvorg
"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.
"Derp de derp."
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.
No sig
The Loki Installer stuff is pretty sweet: http://www.megastep.org/makeself/
Never used it for windows.
If you must release binaries, do it in the Slackware format. They're just tarballs with install scripts. Everyone's got tar.
-- My comment is above.
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.
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.