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
|
| 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
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)
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.
pgsql-pkg-yum by date: