Skip to content

Commit c2e7da1

Browse files
bmomjianbmomjian
committed
I updated RPM related parts in FAQ_DEV against HEAD to be more current.
Devrim GUNDUZ
1 parent 389fad1 commit c2e7da1

File tree

2 files changed

+112
-146
lines changed

2 files changed

+112
-146
lines changed

‎doc/FAQ_DEV

Lines changed: 49 additions & 63 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11

22
Developer's Frequently Asked Questions (FAQ) for PostgreSQL
33

4-
Last updated: Wed Sep 6 20:12:13 EDT 2006
4+
Last updated: Mon Oct 16 15:24:36 EDT 2006
55

66
Current maintainer: Bruce Momjian (bruce@momjian.us)
77

@@ -386,14 +386,14 @@ General Questions
386386

387387
1.14) How are RPMs packaged?
388388

389-
This was written by Lamar Owen:
389+
This was written by Lamar Owen and Devrim Gündüz:
390390

391-
2001-05-03
391+
2006-10-16
392392

393393
As to how the RPMs are built -- to answer that question sanely
394-
requires me to know how much experience you have with the whole RPM
394+
requires us to know how much experience you have with the whole RPM
395395
paradigm. 'How is the RPM built?' is a multifaceted question. The
396-
obvious simple answer is that I maintain:
396+
obvious simple answer is that we maintain:
397397
1. A set of patches to make certain portions of the source tree
398398
'behave' in the different environment of the RPMset;
399399
2. The initscript;
@@ -406,18 +406,26 @@ General Questions
406406
5. The spec file that throws it all together. This is not a trivial
407407
undertaking in a package of this size.
408408

409-
I then download and build on as many different canonical distributions
410-
as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1
411-
on my personal hardware. Occasionally I receive opportunity from
412-
certain commercial enterprises such as Great Bridge and PostgreSQL,
413-
Inc. to build on other distributions.
414-
415-
I test the build by installing the resulting packages and running the
416-
regression tests. Once the build passes these tests, I upload to the
417-
postgresql.org ftp server and make a release announcement. I am also
418-
responsible for maintaining the RPM download area on the ftp site.
419-
420-
You'll notice I said 'canonical' distributions above. That simply
409+
PGDG RPM Maintainer builds the SRPM and announces the SRPM to the
410+
pgsqlrpms-hackers list. This is a list where package builders are
411+
subscribed. Then, the builders download the SRPM and rebuild it on
412+
their machines.
413+
414+
We try to build on as many different canonical distributions as we
415+
can. Currently we are able to build on Red Hat Linux 9, RHEL 3 and
416+
above, and all Fedora Core Linux releases.
417+
418+
To test the binaries, we install them on our local machines and run
419+
regression tests. If the package builders uses postgres user to build
420+
the rpms, then it is possible to run regression tests during RPM
421+
builds.
422+
423+
Once the build passes these tests, the binary RPMs are sent back to
424+
PGDG RPM Maintainer and they are pushed to main FTP site, followed by
425+
a release announcement to pgsqlrpms-* lists, pgsql-general and
426+
pgsql-announce lists.
427+
428+
You will notice we said 'canonical' distributions above. That simply
421429
means that the machine is as stock 'out of the box' as practical --
422430
that is, everything (except select few programs) on these boxen are
423431
installed by RPM; only official Red Hat released RPMs are used (except
@@ -430,54 +438,32 @@ General Questions
430438
compiler is used -- and only the standard official kernel is used as
431439
well.
432440

433-
For a time I built on Mandrake for RedHat consumption -- no more.
434-
Nonstandard RPM building systems are worse than useless. Which is not
435-
to say that Mandrake is useless! By no means is Mandrake useless --
436-
unless you are building Red Hat RPMs -- and Red Hat is useless if
437-
you're trying to build Mandrake or SuSE RPMs, for that matter. But I
438-
would be foolish to use 'Lamar Owen's Super Special RPM Blend Distro
439-
0.1.2' to build for public consumption! :-)
440-
441-
I _do_ attempt to make the _source_ RPM compatible with as many
442-
distributions as possible -- however, since I have limited resources
443-
(as a volunteer RPM maintainer) I am limited as to the amount of
444-
testing said build will get on other distributions, architectures, or
445-
systems.
446-
447-
And, while I understand people's desire to immediately upgrade to the
448-
newest version, realize that I do this as a side interest -- I have a
449-
regular, full-time job as a broadcast
450-
engineer/webmaster/sysadmin/Technical Director which occasionally
451-
prevents me from making timely RPM releases. This happened during the
452-
early part of the 7.1 beta cycle -- but I believe I was pretty much on
453-
the ball for the Release Candidates and the final release.
454-
455-
I am working towards a more open RPM distribution -- I would dearly
456-
love to more fully document the process and put everything into CVS --
457-
once I figure out how I want to represent things such as the spec file
458-
in a CVS form. It makes no sense to maintain a changelog, for
459-
instance, in the spec file in CVS when CVS does a better job of
460-
changelogs -- I will need to write a tool to generate a real spec file
461-
from a CVS spec-source file that would add version numbers, changelog
462-
entries, etc to the result before building the RPM. IOW, I need to
463-
rethink the process -- and then go through the motions of putting my
464-
long RPM history into CVS one version at a time so that version
465-
history information isn't lost.
441+
PGDG RPM Building Project does not build RPMs for Mandrake .
442+
443+
We usually have only one SRPM for all platforms. This is because of
444+
our limited resources. However, on some cases, we may distribute
445+
different SRPMs for different platforms, depending on possible
446+
compilation problems, especially on older distros.
447+
448+
Please note that this is a volunteered job -- We are doing our best to
449+
keep packages up to date. We, at least, provide SRPMs for all
450+
platforms. For example, if you do not find a RHEL 4 x86_64 RPM in our
451+
FTP site, it means that we do not have a RHEL 4 x86_64 server around.
452+
If you have one and want to help us, please do not hesitate to build
453+
rpms and send to us :-)
454+
http://pgfoundry.org/docman/view.php/1000048/98/PostgreSQL-RPM-Install
455+
ation-PGDG.pdf has some information about building binary RPMs using
456+
an SRPM.
457+
458+
PGDG RPM Building Project is a hosted on pgFoundry :
459+
http://pgfoundry.org/projects/pgsqlrpms. We are an open community,
460+
except one point : Our pgsqlrpms-hackers list is open to package
461+
builders only. Still, its archives are visible to public. We use a CVS
462+
server to save the work we have done so far. This includes spec files
463+
and patches; as well as documents.
466464

467465
As to why all these files aren't part of the source tree, well, unless
468-
there was a large cry for it to happen, I don't believe it should.
469-
PostgreSQL is very platform-agnostic -- and I like that. Including the
470-
RPM stuff as part of the Official Tarball (TM) would, IMHO, slant that
471-
agnostic stance in a negative way. But maybe I'm too sensitive to
472-
that. I'm not opposed to doing that if that is the consensus of the
473-
core group -- and that would be a sneaky way to get the stuff into CVS
474-
:-). But if the core group isn't thrilled with the idea (and my
475-
instinct says they're not likely to be), I am opposed to the idea --
476-
not to keep the stuff to myself, but to not hinder the
477-
platform-neutral stance. IMHO, of course.
478-
479-
Of course, there are many projects that DO include all the files
480-
necessary to build RPMs from their Official Tarball (TM).
466+
there was a large cry for it to happen, we don't believe it should.
481467

482468
1.15) How are CVS branches managed?
483469

‎doc/src/FAQ/FAQ_DEV.html

Lines changed: 63 additions & 83 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@
1313
<H1>Developer's Frequently Asked Questions (FAQ) for
1414
PostgreSQL</H1>
1515

16-
<P>Last updated: Wed Sep 6 20:12:13 EDT 2006</P>
16+
<P>Last updated: Mon Oct 16 15:24:36 EDT 2006</P>
1717

1818
<P>Current maintainer: Bruce Momjian (<A href=
1919
"mailto:bruce@momjian.us">bruce@momjian.us</A>)<BR>
@@ -488,15 +488,15 @@ <H3 id="item1.13">1.13) Why don't you use threads, raw
488488

489489
<H3 id="item1.14">1.14) How are RPMs packaged?</H3>
490490

491-
<P>This was written by Lamar Owen:</P>
491+
<P>This was written by Lamar Owen and Devrim Gündüz:</P>
492492

493-
<P>2001-05-03</P>
494-
495-
<P>As to how the RPMs are built -- to answer that question sanely
496-
requires me to know how much experience you have with the whole RPM
497-
paradigm. 'How is the RPM built?' is a multifaceted question. The
498-
obvious simple answer is that I maintain:</P>
493+
<P>2006-10-16</P>
499494

495+
<P>
496+
As to how the RPMs are built -- to answer that question sanely
497+
requires us to know how much experience you have with the whole RPM
498+
paradigm. 'How is the RPM built?' is a multifaceted question. The
499+
obvious simple answer is that we maintain:</P>
500500
<OL>
501501
<LI>A set of patches to make certain portions of the source tree
502502
'behave' in the different environment of the RPMset;</LI>
@@ -515,81 +515,61 @@ <H3 id="item1.14">1.14) How are RPMs packaged?</H3>
515515
trivial undertaking in a package of this size.</LI>
516516
</OL>
517517

518-
<P>I then download and build on as many different canonical
519-
distributions as I can -- currently I am able to build on Red Hat
520-
6.2, 7.0, and 7.1 on my personal hardware. Occasionally I receive
521-
opportunity from certain commercial enterprises such as Great
522-
Bridge and PostgreSQL, Inc. to build on other distributions.</P>
523-
524-
<P>I test the build by installing the resulting packages and
525-
running the regression tests. Once the build passes these tests, I
526-
upload to the postgresql.org ftp server and make a release
527-
announcement. I am also responsible for maintaining the RPM
528-
download area on the ftp site.</P>
529-
530-
<P>You'll notice I said 'canonical' distributions above. That
531-
simply means that the machine is as stock 'out of the box' as
532-
practical -- that is, everything (except select few programs) on
533-
these boxen are installed by RPM; only official Red Hat released
534-
RPMs are used (except in unusual circumstances involving software
535-
that will not alter the build -- for example, installing a newer
536-
non-RedHat version of the Dia diagramming package is OK --
537-
installing Python 2.1 on the box that has Python 1.5.2 installed is
538-
not, as that alters the PostgreSQL build). The RPM as uploaded is
539-
built to as close to out-of-the-box pristine as is possible. Only
540-
the standard released 'official to that release' compiler is used
541-
-- and only the standard official kernel is used as well.</P>
542-
543-
<P>For a time I built on Mandrake for RedHat consumption -- no
544-
more. Nonstandard RPM building systems are worse than useless.
545-
Which is not to say that Mandrake is useless! By no means is
546-
Mandrake useless -- unless you are building Red Hat RPMs -- and Red
547-
Hat is useless if you're trying to build Mandrake or SuSE RPMs, for
548-
that matter. But I would be foolish to use 'Lamar Owen's Super
549-
Special RPM Blend Distro 0.1.2' to build for public consumption!
550-
:-)</P>
551-
552-
<P>I _do_ attempt to make the _source_ RPM compatible with as many
553-
distributions as possible -- however, since I have limited
554-
resources (as a volunteer RPM maintainer) I am limited as to the
555-
amount of testing said build will get on other distributions,
556-
architectures, or systems.</P>
557-
558-
<P>And, while I understand people's desire to immediately upgrade
559-
to the newest version, realize that I do this as a side interest --
560-
I have a regular, full-time job as a broadcast
561-
engineer/webmaster/sysadmin/Technical Director which occasionally
562-
prevents me from making timely RPM releases. This happened during
563-
the early part of the 7.1 beta cycle -- but I believe I was pretty
564-
much on the ball for the Release Candidates and the final
565-
release.</P>
566-
567-
<P>I am working towards a more open RPM distribution -- I would
568-
dearly love to more fully document the process and put everything
569-
into CVS -- once I figure out how I want to represent things such
570-
as the spec file in a CVS form. It makes no sense to maintain a
571-
changelog, for instance, in the spec file in CVS when CVS does a
572-
better job of changelogs -- I will need to write a tool to generate
573-
a real spec file from a CVS spec-source file that would add version
574-
numbers, changelog entries, etc to the result before building the
575-
RPM. IOW, I need to rethink the process -- and then go through the
576-
motions of putting my long RPM history into CVS one version at a
577-
time so that version history information isn't lost.</P>
578-
579-
<P>As to why all these files aren't part of the source tree, well,
580-
unless there was a large cry for it to happen, I don't believe it
581-
should. PostgreSQL is very platform-agnostic -- and I like that.
582-
Including the RPM stuff as part of the Official Tarball (TM) would,
583-
IMHO, slant that agnostic stance in a negative way. But maybe I'm
584-
too sensitive to that. I'm not opposed to doing that if that is the
585-
consensus of the core group -- and that would be a sneaky way to
586-
get the stuff into CVS :-). But if the core group isn't thrilled
587-
with the idea (and my instinct says they're not likely to be), I am
588-
opposed to the idea -- not to keep the stuff to myself, but to not
589-
hinder the platform-neutral stance. IMHO, of course.</P>
590-
591-
<P>Of course, there are many projects that DO include all the files
592-
necessary to build RPMs from their Official Tarball (TM).</P>
518+
<P>PGDG RPM Maintainer builds the SRPM and announces the SRPM to the
519+
pgsqlrpms-hackers list. This is a list where package builders are
520+
subscribed. Then, the builders download the SRPM and rebuild it on their
521+
machines.</P>
522+
523+
<P>We try to build on as many different canonical distributions as we can.
524+
Currently we are able to build on Red Hat Linux 9, RHEL 3 and above,
525+
and all Fedora Core Linux releases.</P>
526+
527+
<P>To test the binaries, we install them on our local machines and run
528+
regression tests. If the package builders uses postgres user to build the
529+
rpms, then it is possible to run regression tests during RPM builds.</P>
530+
531+
<P>Once the build passes these tests, the binary RPMs are sent back to PGDG
532+
RPM Maintainer and they are pushed to main FTP site, followed by a
533+
release announcement to pgsqlrpms-* lists, pgsql-general and
534+
pgsql-announce lists.</P>
535+
536+
<P>You will notice we said 'canonical' distributions above. That simply
537+
means that the machine is as stock 'out of the box' as practical --
538+
that is, everything (except select few programs) on these boxen are
539+
installed by RPM; only official Red Hat released RPMs are used (except
540+
in unusual circumstances involving software that will not alter the
541+
build -- for example, installing a newer non-RedHat version of the Dia
542+
diagramming package is OK -- installing Python 2.1 on the box that has
543+
Python 1.5.2 installed is not, as that alters the PostgreSQL build).
544+
The RPM as uploaded is built to as close to out-of-the-box pristine as
545+
is possible. Only the standard released 'official to that release'
546+
compiler is used -- and only the standard official kernel is used as
547+
well.</P>
548+
549+
<P>PGDG RPM Building Project does not build RPMs for Mandrake .</P>
550+
551+
<P>We usually have only one SRPM for all platforms. This is because of our
552+
limited resources. However, on some cases, we may distribute different
553+
SRPMs for different platforms, depending on possible compilation problems,
554+
especially on older distros.</P>
555+
556+
<P>Please note that this is a volunteered job -- We are doing our best to
557+
keep packages up to date. We, at least, provide SRPMs for all platforms.
558+
For example, if you do not find a RHEL 4 x86_64 RPM in our FTP site, it
559+
means that we do not have a RHEL 4 x86_64 server around. If you have one
560+
and want to help us, please do not hesitate to build rpms and send to us :-)
561+
http://pgfoundry.org/docman/view.php/1000048/98/PostgreSQL-RPM-Installation-PGDG.pdf
562+
has some information about building binary RPMs using an SRPM.</P>
563+
564+
<P>PGDG RPM Building Project is a hosted on pgFoundry :
565+
<a href="http://pgfoundry.org/projects/pgsqlrpms">http://pgfoundry.org/projects/pgsqlrpms</a>.
566+
We are an open community, except one point : Our pgsqlrpms-hackers list is open
567+
to package builders only. Still, its archives are visible to public.
568+
We use a CVS server to save the work we have done so far. This includes
569+
spec files and patches; as well as documents.</P>
570+
571+
<P>As to why all these files aren't part of the source tree, well, unless
572+
there was a large cry for it to happen, we don't believe it should.</P>
593573

594574
<H3 id="item1.15">1.15) How are CVS branches managed?</H3>
595575

0 commit comments

Comments
 (0)