Am resending this as I got no response from the list the first time. It seems that most of the list that uses a database seems to prefer MySQL yet the Red Hat distribution provides Postgresql. I know I'll get a response if I say the following: "Red Hat knows that Postgresql is a superior database package" Least I'll know someone read this. Bye-thanks_TED
When getting ready to install Postgresql (using RPM on Slackware) I looked at the RedHat 6.0 full installation I have on another machine. This ended up in a number of questions about RedHat and Postgres. To start with, I noticed 3 RPM packages (for the full installation). On the Postgres web site I noticed 9 RPM packages and 1 RPM source package. My questions are about the RedHat installation, NOT the Slackware. For example; take Postgres version 6.5.3 and for each of the 9 Postgres binary packages there will be be a 6.5.3-3.i386 and an associated 6.5.3-3nl.i386. There are also 6.5.3-2.i386 and 6.5.3-2nl.386 but these are just an earlier version. My first question is: "What do these pairs mean - why 2 associated binaries? The questions get harder. My second question is that RedHat appears to divide the source code (when building their binary RPMs) so that they end up with a Server package, a Client package, and a Development package. I can see the logic to this (if the Development package contains everything not in the Server and the Client packages - so effectively they have combined the 9 Postgress rpm packages into 3 rpm packages for their distribution) but I don't understand how they can take a single TAR source file and create 3 unique but interdependent binary files. Does the 'SPEC' file do this via MAKE files??? How would this be effected??? I am assuming without further investigation that the single source RPM holds all the answers to this question but maybe someone out there has already spent the time figuring it all out. If so, tell me what you discovered please. My next question is a bit OT (off topic) but some out there may find it interesting. When compiling from source one has to worry about library compatibility. Same is true when installing precompiled binaries. RedHat makes it easy by saying this set of binaries is for 5.2 and this other set is for 6.x. My question is this, "Should I be able to use RPM on the RedHat source rpm file to compile 3 binary packages and then again use RPM to install those binary packages or will using RPM on the source rpm package simply result in binary outputs placed in the default locations ????" I think the latter is the case and that if I want to build the 3 binary packages I would have to use RPM in the build mode. Is there an expert out there that knows the answer to this one. One last question: PLEASE correct me if my assumptions are wrong. I understand the following to be true. RedHat 5.2 binary packages are supposed to be built around glibc2.0.7 which is equivalent to libc6. Also, the glibc2.0.7 library is suppossed to be backwards compatible meaning that the glibc2.0 library supports function calls in libc5 (equivalent to glibc1)for applications compiled in libc5. However, something compiled in glibc2.0.7(libc6) won't run on libc5. To me this means one can run a binary compiled with libc5 on a glibc2.0.7(libc6) system like RedHat5.2. Although, I seem to recall both libraries were present on the RedHat 5.2 distribution. Therefore, compiling something on RedHat5.2 must also build dependencies into the binary in the form of function calls to glibc2.0.7. Now here is the question. Given the above, will a binary compiled on RedHat5.2 run on RedHat 6.0, 6.1, and 6.2??? I don't think the reverse is the case???? Why??? Secondly, which version of RedHat has glibc2.1.x???? So, if there is a GURU out there that compiles in their sleep maybe you could answer these questions for me. Bye-thanks_TED
