RPM Packaging

From PostgreSQL wiki

Revision as of 16:06, 18 May 2012 by Boshomi (Talk | contribs)

Jump to: navigation, search

How are RPMs packaged?

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:

  1. A set of patches to make certain portions of the source tree 'behave' in the different environment of the RPMset;
  2. The initscript;
  3. Any other ancillary scripts and files;
  4. A README.rpm-dist document that tries to adequately document both the differences between the RPM build and the WHY of the differences, as well as useful RPM environment operations (like, using syslog, upgrading, getting postmaster to start at OS boot, etc);
  5. The spec file that throws it all together. This is not a trivial undertaking in a package of this size.

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.

Personal tools