Installing a binary RPM does two things: (a) adds a bunch of files (b) adds information about those files and the RPM from which they came into an RPM database. It may also (c) run some scripts, before and/or after adding the files.
You can see what files a binary RPM will install by doing
rpm -qlp somerpmfile.rpm
You can see what scripts it contains by doing
rpm -qp --scripts somerpmfile.rpm
Which of those scripts get executed and how is slightly longer to explain, reading the free online book "Maximum RPM" from http://www.rpm.org is probably a reasonable place to learn more.
However, maybe I'm being too logical here... if someone doesn't like and doesn't understand RPMs, why would they choose to use Red Hat, which is an RPM-based distribution? And how do they deal with managing all the Red Hat supplied RPM-based content on their systems?
Those prefering .deb packaging can use Debian. Those who prefer tarballs can use Slackware, or roll their own distribution if they really want to. Rocael chose Red Hat 7.1, which uses RPMs.
RPM isn't perfect. Experts who enjoy source compilation and installs, and who know enough to troubleshoot such setups, can rightly claim that this approach is one they know and love and are more comfortable with. That's cool. But to spend literally *days* struggling with an installation issue rather than use RPMs, on an RPM-based distribution... that's something else, to my mind at least.
If the issue is with *my* RPMs, I want to know what it is -- so I can improve them, so they are of more use to more people in the OpenACS community. If the issue is a blanket rejection of RPMs in general, then that's a subjective judgement call, and I can't expect to sucessfully address that... but in that case, I fail to see how Rocael could have managed to install Red Hat 7.1 on his server without using RPMs 😊
I think we are now homing in on the issue surrounding Rocael's library loading problems -- and I have been proposing tests and ideas that do *not* demand RPMs. But it seems only reasonable to point out the relatively greater ease of an RPM-based installation compared to the difficulties he is experiencing, and to try and find out why such an approach was rejected.
