Re: De-duplicating the tree - Mailing list pgsql-pkg-yum

From Craig Ringer
Subject Re: De-duplicating the tree
Date
Msg-id CAMsr+YEGgToo4dZN3qEzZYncWLeBMa9nxRxb6USphuRe7SPNXw@mail.gmail.com
Whole thread Raw
In response to De-duplicating the tree  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: De-duplicating the tree  (Devrim GÜNDÜZ <devrim@gunduz.org>)
List pgsql-pkg-yum
On 3 March 2016 at 21:45, Craig Ringer <craig@2ndquadrant.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


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

pgsql-pkg-yum by date:

Previous
From: Craig Ringer
Date:
Subject: De-duplicating the tree
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: De-duplicating the tree