This is a bit of an abstract - and probably blindingly obvious - question, I know; but what's in a package file? The reason I ask is that I had always assumed that a package (e.g. RPMs) contained pre-compiled binary files that a package manager placed in some standard or specified directory. Then I got to thinking: if the files are all pre-compiled, why does the average RPM file have dependencies? Surely it shouldn't have to rely on something already being there if the programs have already been "made up"?

I get the feeling that this is going to get down to some Linux fundamentals at some stage; so links to webpages that give step-by-step dummy instructions would be helpful!

The reason why RPMS and other Linux packages (yes debs, tgzs, source, etc have dependencies as well) is to make use of shared libraries, files or features provided by other packages. There is no point in bundling files that are provided by other package because they will interefere with each other e.g. overwrite the ones from another package. Creating dependencies on other packages also results in smaller packages because you don't have to bundle all dependencies into one big package and then do the same for other packages.

Yes, programs rely on other programs. As an example, no programs would be running if they didn't have the kernel to run atop of the hardware layer.
Every try running office on a toaster?

The rpm's aka RedHat Package Management files are simply compressed files with archival data, dependency data, timestamp data, size data, and the like as part of the packaging.

RPM packages are also source code. Example, kdelibs3.src.rpm. That is the source code which can be recompiled into a binary, which would be kdelibs.i586.rpm or the like. rpmbuild --rebuild *.src.rpm would render your spanky fresh *.i586.rpm binary.

No man is an island. And no package stands alone, in any OS. It is inefficient to have static libraries and associated files with every package. The packages would end up being very non-modular and windows-like and bloated. And that's bad.

Package managers like apt, urpmi, apt4rpm, yum, and the like use intellect to solve the issues of dependencies. It's a modular strategy towards making yoru system only take what it needs, rather than force feeding you tons of shit you don't.

You have the right idea: a package is just a bunch of precompiled files. They can do some extra work, too. Debian packages (probably redhat.. but I'm not too familiar with RPMs) have the ability to run pre-install scripts and post-install scripts. An example would be to email you that the package is about to be installed and that it is done installing.

The reason a package has dependancies is because the author tries to break the package down into the most maintainable and flexible chunk. This allows you to mix and match with packages.

Lets take openssl for example. You can install the openssl rpm and now have the ability to use openssl (logically). Now lets say you download a tar.gz file that you are going to compile yourself. In order to compile it, it needs the openssl header files. Those are stored in the openssl-devel package. So now you need to install that beforehand. Why split them into two parts? Cleanliness, space, security: if you don't need the devel files, why have them on your system? If an intruder breaks into your system, why give him access to files he doesn't need?

Here's another example on dependancies: Lets say you want to install gaim. Gaim is a GUI application that relies on GTK. You don't have GTK on your computer. When you install gaim, it complains that you don't have GTK. "Screw it, I'll just force it!" So you run

And it forcefully installs gaim. So now you have the (precompiled) gaim files on your computer. When you start the program, it gets furious. "Whoa.. where's GTK at?" and dies. So now you definitely need to install GTK to calm Gaim down.

The obvious solution would be to package Gaim and GTK up together since they go hand in hand. But now you've just made your package bigger. And lets say a security fix comes out for Gaim. That means you need to get a new Gaim+GTK bundle. And what about GIMP? He needs GTK too. So are you going to bundle GIMP+GTK? What about Gaim? Now you've got GIMP+GTK and Gaim+GTK. If one author of the package decided to use an older version of GTK than the other.. you can't have both programs on your computer since you're only allowed 1 GTK (well.. there are ways.. but no.. don't do it..).

Hope that helps a bit

Thanks very much; I think I understand this a little better now!