projects / postgresql.git / commitdiff
| author | Bruce Momjian | |
| Mon, 16 Oct 2006 19:03:43 +0000 (19:03 +0000) | ||
| committer | Bruce Momjian | |
| Mon, 16 Oct 2006 19:03:43 +0000 (19:03 +0000) |
| doc/FAQ_DEV | patch | blob | blame | history | |
| doc/src/FAQ/FAQ_DEV.html | patch | blob | blame | history |
Last updated: Wed Sep 6 20:12:13 EDT 2006
Last updated: Mon Oct 16 15:24:36 EDT 2006
Current maintainer: Bruce Momjian ( This was written by Lamar Owen: This was written by Lamar Owen and Devrim Gündüz: 2001-05-03 As to how the RPMs are built -- to answer that question sanely 2006-10-16 I then download and build on as many different canonical I test the build by installing the resulting packages and You'll notice I said 'canonical' distributions above. That For a time I built on Mandrake for RedHat consumption -- no I _do_ attempt to make the _source_ RPM compatible with as many And, while I understand people's desire to immediately upgrade I am working towards a more open RPM distribution -- I would As to why all these files aren't part of the source tree, well, Of course, there are many projects that DO include all the files PGDG RPM Maintainer builds the SRPM and announces the SRPM to the We try to build on as many different canonical distributions as we can. To test the binaries, we install them on our local machines and run Once the build passes these tests, the binary RPMs are sent back to PGDG You will notice we said 'canonical' distributions above. That simply PGDG RPM Building Project does not build RPMs for Mandrake . We usually have only one SRPM for all platforms. This is because of our Please note that this is a volunteered job -- We are doing our best to PGDG RPM Building Project is a hosted on pgFoundry : As to why all these files aren't part of the source tree, well, unless
-
+
-
-
-
- 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:
+
+
+ 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:
'behave' in the different environment of the RPMset;
trivial undertaking in a package of this size.
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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!
- :-)
-
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- necessary to build RPMs from their Official Tarball (TM).
+
+ pgsqlrpms-hackers list. This is a list where package builders are
+ subscribed. Then, the builders download the SRPM and rebuild it on their
+ machines.
+
+
+ Currently we are able to build on Red Hat Linux 9, RHEL 3 and above,
+ and all Fedora Core Linux releases.
+
+
+ regression tests. If the package builders uses postgres user to build the
+ rpms, then it is possible to run regression tests during RPM builds.
+
+
+ RPM Maintainer and they are pushed to main FTP site, followed by a
+ release announcement to pgsqlrpms-* lists, pgsql-general and
+ pgsql-announce lists.
+
+
+ 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.
+
+
+
+
+ limited resources. However, on some cases, we may distribute different
+ SRPMs for different platforms, depending on possible compilation problems,
+ especially on older distros.
+
+
+ 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.
+
+
+
+ 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.
+
+
+ there was a large cry for it to happen, we don't believe it should.