From c2e7da1f622d9352e839576d9ef1c6ef739b3fce Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Mon, 16 Oct 2006 19:03:43 +0000 Subject: [PATCH] I updated RPM related parts in FAQ_DEV against HEAD to be more current. Devrim GUNDUZ --- doc/FAQ_DEV | 102 +++++++++++++---------------- doc/src/FAQ/FAQ_DEV.html | 134 +++++++++++++++++---------------------- 2 files changed, 101 insertions(+), 135 deletions(-) diff --git a/doc/FAQ_DEV b/doc/FAQ_DEV index 587e3ed02f..0d45b03b52 100644 --- a/doc/FAQ_DEV +++ b/doc/FAQ_DEV @@ -1,7 +1,7 @@ Developer's Frequently Asked Questions (FAQ) for PostgreSQL - Last updated: Wed Sep 6 20:12:13 EDT 2006 + Last updated: Mon Oct 16 15:24:36 EDT 2006 Current maintainer: Bruce Momjian (bruce@momjian.us) @@ -386,14 +386,14 @@ General Questions 1.14) How are RPMs packaged? - This was written by Lamar Owen: + This was written by Lamar Owen and Devrim Gündüz: - 2001-05-03 + 2006-10-16 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 + 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 I maintain: + 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,18 +406,26 @@ General Questions 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. + 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. - 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. + 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. - You'll notice I said 'canonical' distributions above. That simply + 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 @@ -430,54 +438,32 @@ General Questions 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! :-) + PGDG RPM Building Project does not build RPMs for Mandrake . - 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. + 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. - 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. + 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-Install + ation-PGDG.pdf has some information about building binary RPMs using + an SRPM. - 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. + 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, 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). + there was a large cry for it to happen, we don't believe it should. 1.15) How are CVS branches managed? diff --git a/doc/src/FAQ/FAQ_DEV.html b/doc/src/FAQ/FAQ_DEV.html index 1558b35d90..edf3d8c555 100644 --- a/doc/src/FAQ/FAQ_DEV.html +++ b/doc/src/FAQ/FAQ_DEV.html @@ -13,7 +13,7 @@

Developer's Frequently Asked Questions (FAQ) for PostgreSQL

-

Last updated: Wed Sep 6 20:12:13 EDT 2006

+

Last updated: Mon Oct 16 15:24:36 EDT 2006

Current maintainer: Bruce Momjian (bruce@momjian.us)
@@ -488,15 +488,15 @@

1.14) How are RPMs packaged?

-

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 - 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:

+

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. @@ -515,81 +515,61 @@ 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.

+

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.

-

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.

+

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.

-

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.

+

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.

-

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! - :-)

+

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 .

-

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.

+

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.

-

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.

+

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.

-

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).

+

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?