Subject: Minor changes for FAQ_DEV

From: Devrim GUNDUZ <[email-masked]>
Date: Mon, 16 Oct 2006 18:34:02 +0300

Hello,

I updated RPM related parts in FAQ_DEV against HEAD. It has now more
current information. It will be better if someone checks the wording
before committing.

Please apply.

Regards,

-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

*** FAQ_DEV.old	2006-10-16 18:29:47.000000000 +0300
--- FAQ_DEV	2006-10-16 15:26:26.000000000 +0300
***************
*** 1,7 ****
  
            Developer's Frequently Asked Questions (FAQ) for PostgreSQL
                                         
!    Last updated: Wed Sep 6 20:12:13 EDT 2006
     
     Current maintainer: Bruce Momjian ([email-masked])
     
--- 1,7 ----
  
            Developer's Frequently Asked Questions (FAQ) for PostgreSQL
                                         
!    Last updated: Mon Oct  16 15:24:36 EDT 2006
     
     Current maintainer: Bruce Momjian ([email-masked])
     
***************
*** 386,399 ****
     
    1.14) How are RPMs packaged?
    
!    This was written by Lamar Owen:
     
!    2001-05-03
     
     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;
--- 386,399 ----
     
    1.14) How are RPMs packaged?
    
!    This was written by Lamar Owen and Devrim Gündüz:
     
!    2006-10-16
     
     As to how the RPMs are built -- to answer that question sanely
!    requires us 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 we 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;
***************
*** 406,423 ****
      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
--- 406,430 ----
      5. The spec file that throws it all together. This is not a trivial
         undertaking in a package of this size.
         
!    PGDG RPM Maintainer builds the SRPM and announces the SRPM to the 
!    pgsqlrpms-hackers list. This is a list where package builders are 
!    subscribed. Then, the builders download the SRPM and rebuild it on their
!    machines. 
! 
!    We try to build on as many different canonical distributions as we can. 
!    Currently we are able to build on Red Hat Linux 9, RHEL 3 and above, 
!    and all Fedora Core Linux releases.
!    
!    To test the binaries, we install them on our local machines and run
!    regression tests. If the package builders uses postgres user to build the
!    rpms, then it is possible to run regression tests during RPM builds.
! 
!    Once the build passes these tests, the binary RPMs are sent back to PGDG 
!    RPM Maintainer and they are pushed to main FTP site, followed by a 
!    release announcement to pgsqlrpms-* lists, pgsql-general and 
!    pgsql-announce lists.
! 
!    You'll notice we 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
***************
*** 430,484 ****
     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).
!    
    1.15) How are CVS branches managed?
    
     This was written by Tom Lane:
--- 437,467 ----
     compiler is used -- and only the standard official kernel is used as
     well.
     
!    PGDG RPM Building Project does not build RPMs for Mandrake .
! 
!    We usually have only one SRPM for all platforms. This is because of our 
!    limited resources. However, on some cases, we may distribute different 
!    SRPMs for different platforms, depending on possible compilation problems,
!    especially on older distros.
!    
!    Please note that this is a volunteered job -- We are doing our best to 
!    keep  packages up to date. We, at least, provide SRPMs for all platforms. 
!    For example, if you do not find a RHEL 4 x86_64 RPM in our FTP site, it 
!    means that we do not have a RHEL 4 x86_64 server around. If you have one 
!    and want to help us, please do not hesitate to build rpms and send to us :-)
!    http://pgfoundry.org/docman/view.php/1000048/98/PostgreSQL-RPM-Installation-PGDG.pdf
!    has some information about building binary RPMs using an SRPM.
! 
!    PGDG RPM Building Project is a hosted on pgFoundry :
!    http://pgfoundry.org/projects/pgsqlrpms . We are an open community, except 
!    one point : Our pgsqlrpms-hackers list is open to package builders only.
!    Still, its archives are visible to public. We use a CVS server to save
!    the work we have done so far. This includes spec files and patches; as well
!    as documents. 
! 
     As to why all these files aren't part of the source tree, well, unless
!    there was a large cry for it to happen, we don't believe it should.
!   
    1.15) How are CVS branches managed?
    
     This was written by Tom Lane:
*** FAQ_DEV.html.old	2006-10-16 15:12:53.000000000 +0300
--- FAQ_DEV.html	2006-10-16 15:24:40.000000000 +0300
***************
*** 13,19 ****
      <H1>Developer's Frequently Asked Questions (FAQ) for
      PostgreSQL</H1>
  
!     <P>Last updated: Wed Sep  6 20:12:13 EDT 2006</P>
  
      <P>Current maintainer: Bruce Momjian (<A href=
      "mailto:[email-masked]">[email-masked]</A>)<BR>
--- 13,19 ----
      <H1>Developer's Frequently Asked Questions (FAQ) for
      PostgreSQL</H1>
  
!     <P>Last updated: Mon Oct  16 15:24:36 EDT 2006</P>
  
      <P>Current maintainer: Bruce Momjian (<A href=
      "mailto:[email-masked]">[email-masked]</A>)<BR>
***************
*** 488,502 ****
  
      <H3 id="item1.14">1.14) How are RPMs packaged?</H3>
  
!     <P>This was written by Lamar Owen:</P>
  
!     <P>2001-05-03</P>
! 
!     <P>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:</P>
  
      <OL>
        <LI>A set of patches to make certain portions of the source tree
        'behave' in the different environment of the RPMset;</LI>
--- 488,502 ----
  
      <H3 id="item1.14">1.14) How are RPMs packaged?</H3>
  
!     <P>This was written by Lamar Owen and Devrim Gündüz:</P>
  
!     <P>2006-10-16</P>
  
+     <P>
+    As to how the RPMs are built -- to answer that question sanely
+    requires us 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 we maintain:</P>
      <OL>
        <LI>A set of patches to make certain portions of the source tree
        'behave' in the different environment of the RPMset;</LI>
***************
*** 515,595 ****
        trivial undertaking in a package of this size.</LI>
      </OL>
  
!     <P>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.</P>
! 
!     <P>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.</P>
! 
!     <P>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.</P>
! 
!     <P>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!
!     :-)</P>
! 
!     <P>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.</P>
! 
!     <P>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.</P>
! 
!     <P>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.</P>
! 
!     <P>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.</P>
  
!     <P>Of course, there are many projects that DO include all the files
!     necessary to build RPMs from their Official Tarball (TM).</P>
  
      <H3 id="item1.15">1.15) How are CVS branches managed?</H3>
  
--- 515,575 ----
        trivial undertaking in a package of this size.</LI>
      </OL>
  
!    <P>PGDG RPM Maintainer builds the SRPM and announces the SRPM to the 
!    pgsqlrpms-hackers list. This is a list where package builders are 
!    subscribed. Then, the builders download the SRPM and rebuild it on their
!    machines.</P> 
! 
!    <P>We try to build on as many different canonical distributions as we can. 
!    Currently we are able to build on Red Hat Linux 9, RHEL 3 and above, 
!    and all Fedora Core Linux releases.</P>
!    
!    <P>To test the binaries, we install them on our local machines and run
!    regression tests. If the package builders uses postgres user to build the
!    rpms, then it is possible to run regression tests during RPM builds.</P>
! 
!    <P>Once the build passes these tests, the binary RPMs are sent back to PGDG 
!    RPM Maintainer and they are pushed to main FTP site, followed by a 
!    release announcement to pgsqlrpms-* lists, pgsql-general and 
!    pgsql-announce lists.</P>
! 
!    <P>You will notice we 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.</P>
!    
!    <P>PGDG RPM Building Project does not build RPMs for Mandrake .</P>
! 
!    <P>We usually have only one SRPM for all platforms. This is because of our 
!    limited resources. However, on some cases, we may distribute different 
!    SRPMs for different platforms, depending on possible compilation problems,
!    especially on older distros.</P>
!    
!    <P>Please note that this is a volunteered job -- We are doing our best to 
!    keep  packages up to date. We, at least, provide SRPMs for all platforms. 
!    For example, if you do not find a RHEL 4 x86_64 RPM in our FTP site, it 
!    means that we do not have a RHEL 4 x86_64 server around. If you have one 
!    and want to help us, please do not hesitate to build rpms and send to us :-)
!    http://pgfoundry.org/docman/view.php/1000048/98/PostgreSQL-RPM-Installation-PGDG.pdf
!    has some information about building binary RPMs using an SRPM.</P>
! 
!    <P>PGDG RPM Building Project is a hosted on pgFoundry :
!    <a href="http://pgfoundry.org/projects/pgsqlrpms">http://pgfoundry.org/projects/pgsqlrpms</a>. 
!    We are an open community, except one point : Our pgsqlrpms-hackers list is open 
!    to package builders only. Still, its archives are visible to public. 
!    We use a CVS server to save  the work we have done so far. This includes 
!    spec files and patches; as well as documents.</P>
  
!    <P>As to why all these files aren't part of the source tree, well, unless
!    there was a large cry for it to happen, we don't believe it should.</P>
  
      <H3 id="item1.15">1.15) How are CVS branches managed?</H3>

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 16 Oct 2006 15:03:46 -0400 (EDT)

Patch applied.  Thanks.

---------------------------------------------------------------------------

Devrim GUNDUZ wrote:
-- Start of PGP signed section.
> current information. It will be better if someone checks the wording

[ Attachment, skipping... ]

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

-- 
  Bruce Momjian   [email-masked]
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +