Last updated: Wed Sep 6 20:12:13 EDT 2006
Current maintainer: Bruce Momjian (bruce@momjian.us)
--- 13,19 ----
Last updated: Mon Oct 16 15:24:36 EDT 2006
Current maintainer: Bruce Momjian (bruce@momjian.us)
***************
*** 488,502 ****
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:
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:
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).
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 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.
! !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.