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 PROTECTED])
--- 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 PROTECTED])
***************
*** 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 PROTECTED]">[EMAIL PROTECTED]</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 PROTECTED]">[EMAIL PROTECTED]</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>
signature.asc
Description: This is a digitally signed message part
