Re: Packaging 7.1.1 - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Packaging 7.1.1 |
Date | |
Msg-id | 200111271827.fARIRVQ01372@candle.pha.pa.us Whole thread Raw |
In response to | Re: Packaging 7.1.1 (Lamar Owen <lamar.owen@wgcr.org>) |
Responses |
Developers FAQ (was:Re: Packaging 7.1.1)
|
List | pgsql-hackers |
I have added this to the developer's FAQ. --------------------------------------------------------------------------- > 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 different environment of the RPMset; > 2.) The initscript; > 3.) Any other ancilliary 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. > > 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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: