Re: Packaging 7.1.1 - Mailing list pgsql-hackers
From | Lamar Owen |
---|---|
Subject | Re: Packaging 7.1.1 |
Date | |
Msg-id | 3AF2043D.526670C@wgcr.org Whole thread Raw |
In response to | RE: Packaging 7.1.1 (Rachit Siamwalla <rachit@ensim.com>) |
Responses |
Re: Packaging 7.1.1
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Packaging 7.1.1 (Bruce Momjian <pgman@candle.pha.pa.us>) Re: Packaging 7.1.1 (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-hackers |
Rachit Siamwalla wrote: > oh btw, i completely forgot to mention the minor fixes to the linux init > scripts i mentioned earlier (about 2 weeks ago) for things that perhaps > should be in the 7.1.1 release. (someone sent out a mail that they were > branching 7.1.1) > Also i never got a response on who actually packages those linux init > scripts that appear in the RPM but not on the pgsql cvs tree. (i am also > curious on why it is different, and how the RPM is built). That would be me. Before building and releasing 7.1.1 RPMs I will be reviewing the various bugs and changes planned for the 7.1.1 RPM. As to why the RPM init script is different from the one packaged in the main source tree -- I can make assumptions in the RPM set that the version in the source tree cannot. 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:1.) A set of patches to make certain portions of the source tree 'behave' in the differentenvironment of the RPMset;2.) The initscript;3.) Any other ancilliary scripts and files;4.) A README.rpm-distdocument 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 apackage 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 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. 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. 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). Bruce, should portions of that answer be part of the linux FAQ? I don't want to have to write that too many times :-). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
pgsql-hackers by date: