From: Bruce Momjian Date: Mon, 26 Nov 2001 21:56:40 +0000 (+0000) Subject: Update FAQ_DEV. X-Git-Tag: REL9_0_0~18934 X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=b7ca9a9403f9cd597899e4ffa06ed6e6afb00c2c;p=pg-rex%2Fsyncrep.git Update FAQ_DEV. --- diff --git a/doc/src/FAQ/FAQ_DEV.html b/doc/src/FAQ/FAQ_DEV.html index 94306bdbe4..f3519893b6 100644 --- a/doc/src/FAQ/FAQ_DEV.html +++ b/doc/src/FAQ/FAQ_DEV.html @@ -51,6 +51,7 @@ 12) How do I add a new port?
13) What is CommandCounterIncrement()?
14) Why don't we use threads in the backend?
+ 15) How are RPM's packaged?

@@ -68,7 +69,8 @@ ccsym find standard defines made by your compiler entab converts tabs to spaces, used by pgindent find_static finds functions that could be made static - find_typedef get a list of typedefs in the source code + find_typedef finds a list of typedefs in the source code + find_badmacros finds macros that use braces incorrectly make_ctags make vi 'tags' file in each directory make_diff make *.orig and diffs of source make_etags make emacs 'etags' files @@ -539,6 +541,99 @@
  • The backend code would be more complex.
    • + +

    15) How are RPM's packaged?

    + +

    This is from Lamar Owen:

    +
    +As to how the RPMs are built -- to answer that question sanely requires
+me to know how much experience you have with the whole RPM paradigm. 
+'How is the RPM built?' is a multifaceted question.  The obvious simple
+answer is that I maintain:
+	1.)	A set of patches to make certain portions of the source
+		tree 'behave' in the different environment of the RPMset;
+	2.)	The initscript;
+	3.)	Any other ancilliary scripts and files;
+	4.)	A README.rpm-dist document that tries to adequately document
+		both the differences between the RPM build and the WHY of the
+		differences, as well as useful RPM environment operations
+		(like, using syslog, upgrading, getting postmaster to
+		start at OS boot, etc);
+	5.)	The spec file that throws it all together.  This is not a 
+		trivial undertaking in a package of this size.
+
+I then download and build on as many different canonical distributions
+as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on
+my personal hardware.  Occasionally I receive opportunity from certain
+commercial enterprises such as Great Bridge and PostgreSQL Inc to build
+on other distributions.  
+
+I test the build by installing the resulting packages and running the
+regression tests.  Once the build passes these tests, I upload to the
+postgresql.org ftp server and make a release announcement.  I am also
+responsible for maintaining the RPM download area on the ftp site.
+
+You'll notice I said 'canonical' distributions above.  That simply means
+that the machine is as stock 'out of the box' as practical -- that is,
+everything (except select few programs) on these boxen are installed by
+RPM; only official Red Hat released RPMs are used (except in unusual
+circumstances involving software that will not alter the build -- for
+example, installing a newer non-RedHat version of the Dia diagramming
+package is OK -- installing Python 2.1 on the box that has Python 1.5.2
+installed is not, as that alters the PostgreSQL build).  The RPM as
+uploaded is built to as close to out-of-the-box pristine as is
+possible.  Only the standard released 'official to that release'
+compiler is used -- and only the standard official kernel is used as
+well.
+
+For a time I built on Mandrake for RedHat consumption -- no more. 
+Nonstandard RPM building systems are worse than useless.  Which is not
+to say that Mandrake is useless!  By no means is Mandrake useless --
+unless you are building Red Hat RPMs -- and Red Hat is useless if you're
+trying to build Mandrake or SuSE RPMs, for that matter.  But I would be
+foolish to use 'Lamar Owen's Super Special RPM Blend Distro 0.1.2' to
+build for public consumption! :-)
+
+I _do_ attempt to make the _source_ RPM compatible with as many
+distributions as possible -- however, since I have limited resources (as
+a volunteer RPM maintainer) I am limited as to the amount of testing
+said build will get on other distributions, architectures, or systems.  
+
+And, while I understand people's desire to immediately upgrade to the
+newest version, realize that I do this as a side interest -- I have a
+regular, full-time job as a broadcast
+engineer/webmaster/sysadmin/Technical Director which occasionally
+prevents me from making timely RPM releases. This happened during the
+early part of the 7.1 beta cycle -- but I believe I was pretty much on
+the ball for the Release Candidates and the final release.
+
+I am working towards a more open RPM distribution -- I would dearly love
+to more fully document the process and put everything into CVS -- once I
+figure out how I want to represent things such as the spec file in a CVS
+form.  It makes no sense to maintain a changelog, for instance, in the
+spec file in CVS when CVS does a better job of changelogs -- I will need
+to write a tool to generate a real spec file from a CVS spec-source file
+that would add version numbers, changelog entries, etc to the result
+before building the RPM.  IOW, I need to rethink the process -- and then
+go through the motions of putting my long RPM history into CVS one
+version at a time so that version history information isn't lost.
+
+As to why all these files aren't part of the source tree, well, unless
+there was a large cry for it to happen, I don't believe it should. 
+PostgreSQL is very platform-agnostic -- and I like that.  Including the
+RPM stuff as part of the Official Tarball (TM) would, IMHO, slant that
+agnostic stance in a negative way.  But maybe I'm too sensitive to
+that.  I'm not opposed to doing that if that is the consensus of the
+core group -- and that would be a sneaky way to get the stuff into CVS
+:-).  But if the core group isn't thrilled with the idea (and my
+instinct says they're not likely to be), I am opposed to the idea -- not
+to keep the stuff to myself, but to not hinder the platform-neutral
+stance. IMHO, of course.  
+
+Of course, there are many projects that DO include all the files
+necessary to build RPMs from their Official Tarball (TM).
+
    +