Peter Blomgren wrote:
> 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.
Peter
Thanks you so very much for your effort on my behalf. I agree about emacs. I
read the README for which you provided a URL. The README made me nervous
regarding some problems as well as upgrading. Finally I will be re-reading your
note a few times. Very nice of you to take as much trouble as you have done and
reply. I have a much better appreciation as to what's involved in using
Postgresql on Red Hat. Also, thank you for the tutorial approach to my problem.
Very much appreciated.
Thanks again!
Do have a nice day.
Bye-thanks_TED
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
