Re: De-duplicating the tree

On 3 March 2016 at 21:45, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> That'll bring the number of changes needed for many packages from 20+ down
> to 3-5 for a common update.
>

BTW, if that works out I think the next step would be to template the
specfiles, substituting the pg version into them. So we could then have a
*single* spec file for all supported versions, at the cost of having to do
some simple template substitutions on specs. This is what I've done very
successfully in 2ndQuadrant's repositories and build scripts, so I can
build things like pglogical for all supported Pg versions on all supported
arches and hosts with a *single* command, from a *single* spec file,
complete with rpm signing etc.

RPM macros aren't really suitable for this because rpm offers no way to
embed macros in a .srpm, so you need to know the extra macros to --define
at rpmbuild --rebuild time to get the expected result. Not desirable, a
srpm should be self-contained. Hence templating the spec files.

For files that're reused across all supported versions as well, we could
symlink like:

rpm/redhat/9.5/repmgr/EL-6/repmgr.spec.in
=> rpm/redhat/common/repmgr/repmgr.spec.in

where repmgr.spec.in is the existing specfile that simply has:

%global pgmajorversion __PG_MAJOR_SHORT__
%global pgpackageversion __PG_MAJOR__

There's already a Makefile, so adding rules for templated files is trivial
and can be done via Makefile.global to make it a one-liner like

PG_VERSION_SUBST := repmgr.in repmgr.conf.sample.patch.in

The rules we'd generate would be like:

repmgr.spec: repmgr.spec.in
sed -e 's/__PG_MAJOR_SHORT__/$(pg_major_short)/' \
-e 's/__PG_MAJOR__/$(pg_major)/' \
$< > $@

the makevars pg_major_short and pg_major can be determined automatically
from the makefile's path so there's no need to put the version in the
Makefile.

(BTW, the DIST that's currently set manually in each Makefile can also be
determined from the makefile path automatically)

With that done your build scripts should stay happy and be able to invoke
the Makefiles without knowing anything's changed.

Then I can probably patch Makefile.global to allow use of mock/mockchain
just by passing USE_MOCK=1 to make, referencing a localrepo for build
dependencies, so it becomes possible for anyone to rebuild anything in the
source tree and expect it to work. That in turn leads to easy automated
testing...

Sound like a sane direction? I don't want to tackle all that at once - for
one thing, time is a concern. But starting with symlinking into common dirs
*within* a pg major version and maybe autodetecting DIST so the Makefile
can be shared would be a beginning.

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