*** 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 (bruce@momjian.us) --- 1,7 ---- Developer's Frequently Asked Questions (FAQ) for PostgreSQL ! Last updated: Mon Oct 16 15:24:36 EDT 2006 Current maintainer: Bruce Momjian (bruce@momjian.us) *************** *** 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: