Re: a bunch of potential improvements to the postgresql spec files

On Fri, Dec 9, 2016 at 12:41 PM, Devrim Gündüz <devrim(at)gunduz(dot)org> wrote:

>
> Hi Jonathon,
>
> First of all, thank your for working on this. Comments inline:
>
> On Fri, 2016-12-02 at 14:06 -0600, Jonathon Nelson wrote:
> >
> > 0. globally replace /usr/sbin with %{_sbindir}, /usr/bin with %{_bindir},
> > and /usr/share/man with %{_mandir}
>
> Looks good.
>
> > 1. Remove the redundant use of 0%{?rhel} in tests for RHEL-specific
> values.
> > Turns:
> > %if 0%{?rhel} && 0%{rhel} > 6
> > into:
> > %if 0%{rhel} > 6
>
> If we remove that one, then Fedora builds should fail.
>

Ah! I think I meant to suggest this:

%if 0%{rhel} > 6
(note the addition of the question mark). That should be logically
equivalent to
%if 0%{?rhel} && 0%{rhel} > 6

>
...

> 8. Replace all repetitive blocks for update-alternatives with for loop
> > *AND* use %{mandir} and %{bindir} (per item 0):
> >
> > %{_sbindir}/update-alternatives --install %{bindir}/psql pgsql-psql
> > %{pgbaseinstdir}/bin/psql %{packageversion}0
> > %{_sbindir}/update-alternatives --install %{bindir}/clusterdb
> > pgsql-clusterdb %{pgbaseinstdir}/bin/clusterdb %{packageversion}0
> > ...
> > %{_sbindir}/update-alternatives --install %{bindir}/pg_basebackup
> > pgsql-pg_basebackup %{pgbaseinstdir}/bin/pg_basebackup
> %{packageversion}0
> > ...
> >
> > with:
> >
> > for i in \
> > pgbench pg_test_timing pg_upgrade pg_xlogdump pg_archivecleanup \
> > pg_config pg_isready pg_test_fsync pg_receivexlog \
> > psql clusterdb \
> > createdb createlang createuser \
> > dropdb droplang dropuser \
> > pg_basebackup pg_dump pg_dumpall pg_restore \
> > reindexdb vacuumdb; do
> > %{_sbindir}/update-alternatives --install %{bindir}/${i}
> > pgsql-${i} %{pgbaseinstdir}/bin/${i} %{packageversion}0
> > %{_sbindir}/update-alternatives --install %{mandir}/man1/${i}.1
> > pgsql-${i}man %{pgbaseinstdir}/share/man/man1/${i}.1
> %{packageversion}0
> > done
>
> This line creates alternatives for *all* binaries, but we don't do this. We
> only create alternatives entries for the binaries that can work across
> major
> releases -- but I liked the approach. Will apply with a few changes.
>

Thanks! I found that not having ready access to the latest versions of
many of those binaries (without having to specify the full path) was a
pain. Plus, isn't that why alternatives exists?

I will try to push these changes in next minor release set.
>

Thanks!