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