Re: Unifying the spec files?

On 08/01/2014 01:35 AM, Craig Ringer wrote:
> On 07/30/2014 11:39 PM, Craig Ringer wrote:
>> Still some bugs to fix in the unified package and more testing to
>> do but I'm happy with how things are looking. I'll probably need to
>> make new mock targets too, of course, but that looks trivial.
>
> I'm down to testing now. Looking good so far.

OK, I think I'm largely done with this. I've done the most recent round
of testing on BDR RPMs based on this work, but the stock Pg RPMs are
only trivially different so it should be fine.

I've made a lot of changes since the last update:

- Fixed a bunch of package bugs, including that Perl dependency bug

- Used a single sed statement to insert placeholders in all the
scripts, instead of individual statements with different placeholders
for each script

- in the %check section, verify no placeholders are left over after
package build

- I've gone through and parameterized all references to the package
name, version, etc, and tested that these can be changed by modifying
defines in the package. These changes are substituted into any
scripts built for the package, and I'm using these changes in BDR
package testing.

- Produced a build automation script. It's not intended for long term
use, but it's good for testing. Koji should be used for in the medium-
long term. It also does some post-build sanity checks and I'm setting
up some scripts with vagrant to do proper ones.

The script also creates a yum repo with yum metadata and repoview
data.

- New mock targets that include PGDG repositories (and, for RHEL/CentOS,
EPEL repositories). They're disabled by default but can be enabled
on demand to install specific packages during mock setup, though this
needs a patched mock from http://github.com/ringerc/mock . Upstream
is merging the patches.

- Inline documentation in the spec file

- Several script fixes

Outstanding issues:

- Need to change the RHEL5 package to build against libuuid

- Should expose a new Provides: that can be depended on by extensions
to allow finer control of what extensions will install on what
servers.

- More testing, specially on CentOS/RHEL and on sysvinit systems in
general.

- pg_upgrade support is disabled. It's been broken in PGDG since 9.2
anyway, and I suspect it should simply be removed from
postgresql94-setup in favour of documenting how to do it properly
by hand. The code's there, but hasn't been tested.

If this is to be re-enabled we need test automation to make sure
it actually works for a variety of scenarios.

Quickstart to try it out, on a freshly installed clean Fedora 20 box
(use EC2, vagrant, real hw, whatever), assuming that the scripts are in
a directory named 'packaging':

# Install tools
yum groupinstall "Development Tools"
yum install yum-utils rpmdevtools repoview createrepo
yum-builddep mock
yum install git svn
# You only need this to make the postgresql dist tarball
# because configure has to run:
yum-builddep postgresql
# and for the docs in the dist tarball:
yum install openjade jadetex docbook-dtds docbook5-schemas
docbook-style-dsssl docbook-style-xsl

# Install patched mock
git clone https://github.com/ringerc/mock.git
pushd mock
git checkout target-paths
./autogen.sh
./configure
make rpm
yum install noarch/*
popd

# Grab sources and create source tarball
git clone git://git.postgresql.org/git/postgresql.git
pushd postgresql
# whatever bdr you want to build; remember to change the
# SRPM to match
git checkout REL9_4_STABLE
# No need for any options, it's only to create the makefiles
# for "make dist".
./configure
make dist
popd

pushd packaging
pushd unified-rpm
mv ../../postgresql/*.bz2 .
spectool -gf postgresql94.spec
# If needed, edit unified-rpm/postgresql94.spec, particularly
# the version defines and the Source0 line for the Pg sources;
# then:
popd
./mock-build-all.sh

The first run will take longer because it has to set up and cache the
mock chroots.

You can limit the build to only some targets, see the targets variable
in mock-build-all.sh .

If you want to test the packages you built locally, without pushing to a
remote repo, you need only define a repo in yum with the file:// URL to
your locally built repo.

I'll put the WIP unified packages in a public git repo soon; right now
they're in a private tree associated with BDR work. For now, the current
versions are attached.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services