Skip to content

P
Postgres FD Implementation
Commit c2e7da1f authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

I updated RPM related parts in FAQ_DEV against HEAD to be more current. 

Devrim GUNDUZ
parent 389fad1e
Hide whitespace changes
Inline Side-by-side
Showing with 112 additions and 146 deletions
doc/FAQ_DEV
View file @ c2e7da1f
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.
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
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
......@@ -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! :-)
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.
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-Install
ation-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, 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?
......
doc/src/FAQ/FAQ_DEV.html
View file @ c2e7da1f
......@@ -13,7 +13,7 @@
<H1>Developer's Frequently Asked Questions (FAQ) for
PostgreSQL</H1>
<P>Last updated: Wed Sep 6 20:12:13 EDT 2006</P>
<P>Last updated: Mon Oct 16 15:24:36 EDT 2006</P>
<P>Current maintainer: Bruce Momjian (<A href=
"mailto:bruce@momjian.us">bruce@momjian.us</A>)<BR>
......@@ -488,15 +488,15 @@
<H3 id="item1.14">1.14) How are RPMs packaged?</H3>
<P>This was written by Lamar Owen:</P>
<P>This was written by Lamar Owen and Devrim Gündüz:</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>
<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,81 +515,61 @@
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>
<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>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment