@@ -51,6 +51,7 @@ <H2>Questions</H2>
5151< A href ="#12 "> 12</ A > ) How do I add a new port?< BR >
5252< A href ="#13 "> 13</ A > ) What is CommandCounterIncrement()?< BR >
5353< A href ="#14 "> 14</ A > ) Why don't we use threads in the backend?< BR >
54+ < A href ="#15 "> 15</ A > ) How are RPM's packaged?< BR >
5455< BR >
5556
5657< HR >
@@ -68,7 +69,8 @@ <H3><A name="1">1</A>) What tools are available for
6869 ccsym find standard defines made by your compiler
6970 entab converts tabs to spaces, used by pgindent
7071 find_static finds functions that could be made static
71- find_typedef get a list of typedefs in the source code
72+ find_typedef finds a list of typedefs in the source code
73+ find_badmacros finds macros that use braces incorrectly
7274 make_ctags make vi 'tags' file in each directory
7375 make_diff make *.orig and diffs of source
7476 make_etags make emacs 'etags' files
@@ -539,6 +541,99 @@ <H3><A name="14">14</A>) Why don't we use threads in the
539541
540542< LI > The backend code would be more complex.</ LI >
541543</ UL >
544+
545+ < H3 > < A name ="15 "> 15</ A > ) How are RPM's packaged?</ H3 >
546+
547+ < P > This is from Lamar Owen:</ P >
548+ < PRE >
549+ As to how the RPMs are built -- to answer that question sanely requires
550+ me to know how much experience you have with the whole RPM paradigm.
551+ 'How is the RPM built?' is a multifaceted question. The obvious simple
552+ answer is that I maintain:
553+ 1.)A set of patches to make certain portions of the source
554+ tree 'behave' in the different environment of the RPMset;
555+ 2.)The initscript;
556+ 3.)Any other ancilliary scripts and files;
557+ 4.)A README.rpm-dist document that tries to adequately document
558+ both the differences between the RPM build and the WHY of the
559+ differences, as well as useful RPM environment operations
560+ (like, using syslog, upgrading, getting postmaster to
561+ start at OS boot, etc);
562+ 5.)The spec file that throws it all together. This is not a
563+ trivial undertaking in a package of this size.
564+
565+ I then download and build on as many different canonical distributions
566+ as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on
567+ my personal hardware. Occasionally I receive opportunity from certain
568+ commercial enterprises such as Great Bridge and PostgreSQL Inc to build
569+ on other distributions.
570+
571+ I test the build by installing the resulting packages and running the
572+ regression tests. Once the build passes these tests, I upload to the
573+ postgresql.org ftp server and make a release announcement. I am also
574+ responsible for maintaining the RPM download area on the ftp site.
575+
576+ You'll notice I said 'canonical' distributions above. That simply means
577+ that the machine is as stock 'out of the box' as practical -- that is,
578+ everything (except select few programs) on these boxen are installed by
579+ RPM; only official Red Hat released RPMs are used (except in unusual
580+ circumstances involving software that will not alter the build -- for
581+ example, installing a newer non-RedHat version of the Dia diagramming
582+ package is OK -- installing Python 2.1 on the box that has Python 1.5.2
583+ installed is not, as that alters the PostgreSQL build). The RPM as
584+ uploaded is built to as close to out-of-the-box pristine as is
585+ possible. Only the standard released 'official to that release'
586+ compiler is used -- and only the standard official kernel is used as
587+ well.
588+
589+ For a time I built on Mandrake for RedHat consumption -- no more.
590+ Nonstandard RPM building systems are worse than useless. Which is not
591+ to say that Mandrake is useless! By no means is Mandrake useless --
592+ unless you are building Red Hat RPMs -- and Red Hat is useless if you're
593+ trying to build Mandrake or SuSE RPMs, for that matter. But I would be
594+ foolish to use 'Lamar Owen's Super Special RPM Blend Distro 0.1.2' to
595+ build for public consumption! :-)
596+
597+ I _do_ attempt to make the _source_ RPM compatible with as many
598+ distributions as possible -- however, since I have limited resources (as
599+ a volunteer RPM maintainer) I am limited as to the amount of testing
600+ said build will get on other distributions, architectures, or systems.
601+
602+ And, while I understand people's desire to immediately upgrade to the
603+ newest version, realize that I do this as a side interest -- I have a
604+ regular, full-time job as a broadcast
605+ engineer/webmaster/sysadmin/Technical Director which occasionally
606+ prevents me from making timely RPM releases. This happened during the
607+ early part of the 7.1 beta cycle -- but I believe I was pretty much on
608+ the ball for the Release Candidates and the final release.
609+
610+ I am working towards a more open RPM distribution -- I would dearly love
611+ to more fully document the process and put everything into CVS -- once I
612+ figure out how I want to represent things such as the spec file in a CVS
613+ form. It makes no sense to maintain a changelog, for instance, in the
614+ spec file in CVS when CVS does a better job of changelogs -- I will need
615+ to write a tool to generate a real spec file from a CVS spec-source file
616+ that would add version numbers, changelog entries, etc to the result
617+ before building the RPM. IOW, I need to rethink the process -- and then
618+ go through the motions of putting my long RPM history into CVS one
619+ version at a time so that version history information isn't lost.
620+
621+ As to why all these files aren't part of the source tree, well, unless
622+ there was a large cry for it to happen, I don't believe it should.
623+ PostgreSQL is very platform-agnostic -- and I like that. Including the
624+ RPM stuff as part of the Official Tarball (TM) would, IMHO, slant that
625+ agnostic stance in a negative way. But maybe I'm too sensitive to
626+ that. I'm not opposed to doing that if that is the consensus of the
627+ core group -- and that would be a sneaky way to get the stuff into CVS
628+ :-). But if the core group isn't thrilled with the idea (and my
629+ instinct says they're not likely to be), I am opposed to the idea -- not
630+ to keep the stuff to myself, but to not hinder the platform-neutral
631+ stance. IMHO, of course.
632+
633+ Of course, there are many projects that DO include all the files
634+ necessary to build RPMs from their Official Tarball (TM).
635+ </ PRE >
636+
542637</ BODY >
543638</ HTML >
544639