Re: Packaging 7.1.1

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