Ted,
I was too tired to touch this the first time around... There
are multiple issues here all bundled up in a big tar-ball of
confusion, but I'll take a stab at it.
> I know I'll get a response if I say the following: "Red Hat knows
> that Postgresql is a superior database package"
Even better: "emacs is better than vi" :-)
> [ postgresql-6.5.3-3.i386.rpm vs. postgresql-6.5.3-3nl.i386.rpm ]
> My first question is: "What do these pairs mean - why 2 associated binaries?
See section "POSTGRESQL RPM PACKAGES AND RATIONALE." in
ftp://ftp.postgresql.org/pub/RPMS/README.rpm.txt
> My second question is that RedHat appears to divide the [...] code
> (when building their binary RPMs) so that they
> end up with a Server package, a Client package, and a Development
> package. [...] 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???
You're invoking "SPEC" and "MAKE" like the are spells out of some
old-school Infocom text adventure. :-) The spec file is the
recipe describing how to build the binary rpms from the source
tar-ball (or multiple tar-balls, and/or patches, etc... but for
simplicity, lets assume it's a single tar-file). It describes,
among other things, the options passed to make (the magical Makefiles
are in the tar-ball). In particular it describes where the files
of the RPMs are to be installed, and what files go into which rpm --
yes, one SRPM can be the parent of multiple RPMs. If you were really
sick and twisted you could put each file into its own RPM and have all
the RPMs depend on each other, but dividing things into -client, -server,
and -devel makes a lot more sense: you install -client if you need to
connect to a database, -server if you are providing the database, and
-devel if you are building other applications that integrates the database.
> I am assuming without further investigation that the single source
> RPM holds all the answers to this question
You are correct. I strongly suggest you do some investigating;
it's fun and educational.
> 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.
rpm --rebuild some_application.src.rpm
builds the binary RPMs, which you then install. During the building
process, the files will be put "somewhere." For all redhat packages
this "somewhere" (RPM_BUILD_ROOT) is out of the way of your
regular files (so nothing gets overwritten), but if you're downloading
SRPMs from unofficial places, I suggest taking a peak at the spec
file to make sure the build process is not going to interfere with
the installed system.
rpm -i some_application.src.rpm
Installs the tar-ball, patches, etc. in /usr/src/redhat/SOURCES, and
the spec file in /usr/src/redhat/SPECS. Then (in /usr/src/redhat/SPECS)
you run 'rpm -ba some_application.spec' to build the RPMs.
> One last question: PLEASE correct me if my assumptions are wrong.
The glibc2-based RH distributions include libc5 (5.3.12) libraries for
backwards compatibility, so yes, something compiled on an old
distribution should -- in theory at least -- run on a new distribution.
Since new libraries are supersets of old ones, the reverse is rarely
true -- it's very difficult to be forward compatible.
RH6.1 has glibc2.1.2
RH6.2 has glibc2.1.3
> So, if there is a GURU out there that compiles in their sleep maybe you
> could answer these questions for me.
Actually, I do compile while I sleep -- some builds take a long time. :-)
When all else fails, read the manual.
--
\Peter.
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
