Every programming course is good.

Just something that you can use:

http://www.autorpm.org/

It's a perl based rpm installer that automatically handles dep issues. Gnorpm and kpackage still have problems with this.

Surely InstallShield doesn't do anything rpms don't? I mean it certainly doesn't automatically install dependencies. I suppose it puts a pretty GUI on top of the installation, but many distros have some kind of GUI for managing rpms anyway.

I think the dependecy problem will never go away. It's an inevitable result of there being so many commonly used libraries which are all being updated out of synch.

Alex

Actually Install shield on windows does install all dependencies. It installs all dll's not already existing on the system that the program needs. If it didn't you'd have the same problem in windows as you do in linux.

Doesn't URPMI also sort out dependencies? I've been looking for a script for Mandrake which will check for security updates and then install them automatically, just like apt-get - won't urpmi carry this out?

A combination of urpmi.update -a and then urpmi --auto-select and --force?

Ok, my bad.

I think the problem with automatically handling dependencies is not really an issue of just writing some InstallShield-like program. I think there are two main issues involved. The first is keeping large amounts of current data on inter-package dependencies; RPMs already do this. The second is keeping data on how a package can be obtained; RPMS do not do hold this information, and so it is not possible to automatically install RPM dependencies unless those dependencies are distributed with the dependant RPM.

The *BSD ports system, of course, does know how to obtain packages, and it does automatic dependency installation pretty smoothely.

So appart from the fact that RPMs suck, my conclusion is that for an InstallShield-like program for Linux to work properly, something similar to the *BSD ports database would have to be built first. For this to work properly, every Linux distribution would have to agree to use the same central database holding information on where packages could be obtained. To me this seems unlikely to happen, although the rpmfind database could perhaps be used as a starting point.

I suppose an alternative would be to distribute programs with their dependencies (as with Windows), but since different people have different packages installed, it would be hard to know which dependencies to include and which to leave out. Also, this would massively increase the size of every package, even though some of the dependencies the package came with didn't have to be installed.

[apologies for length of post]

Alex

Linking statically is not nessary. If more apps would just distribute it with the dynamically linked libraries and do a check for which one the system needs then you would have an install that would work without having to find all of its dependencies.

When you link it statically, your programs become bigger. It's not a good idea. Especially in Linux.

Ok I've just edited that last post very heavily (before I saw the two replies).

Good point about the size of statically linked programs.

Alex

Good change. Now I agree with you

I agree, too.