Re: BUG #14299: initdb and man pages are not installed in the alternatives system

Hi Devrim,

Thanks for the quick reply.

On Tue, 30 Aug 2016 11:24:03 +0300
Devrim Gündüz <devrim@gunduz.org> wrote:

> Hi Karl,
>
> On Sat, 2016-08-27 at 15:50 +0000, kop@meme.com wrote:
> > Bug reference:      14299
> > Logged by:          Karl Pinc
> > Email address:      kop@meme.com
> > PostgreSQL version: 9.5.4
> > Operating system:   RHEL 7
> > Description:        

> > Just installed PG 9.5 on a RHEL 7 box.  While client programs like
> > psql and db_dump are installed in the alternatives system, initdb,
> > and perhaps other server side programs, are not.  Consequently I
> > must invoke initdb with a fully qualified path.
>
> This is intentional. We only create alternatives links for the
> binaries that are cross version compatible. That is a natural effect
> of being able to multiple version of RPMs.
>
> > I can see man pages for psql (etc.) but not initdb. 
>
> Actually initdb, etc. are just not under MANPATH:
>
> man /usr/pgsql-9.5/share/man/man1/initdb.1
>
> would work.

Right.  What I'm intending to request here is that I not have
to use fully qualified paths, whether for man pages or binaries.

> >  And I can't see any man pages for SQL commands like CREATE
> > DATABASE.  By this I mean they are not in my MANPATH.  I presume
> > this is because they are not under the control of the alternatives
> > system.
>
> I am not aware that we have man pages for SQL commands. You are
> welcome to send patches
> via https://redmine.postgresql.org/projects/pgrpms/issues .

RH/Centos generates man7 pages of SQL commands using help2man.
See line 86 of the centos spec file:

https://git.centos.org/blob/rpms!rh-postgresql95/36d55031946317af5a4f56f69d807ed907eb520c/SPECS!rh-postgresql95.spec;jsessionid=vgg48opqwpk36x9pnf4k2j2z

Apologies for not sending a patch.

Debian also generates man pages for all the SQL commands.
These seem to be the psql \h output, although I've not
looked to see how it's done.

> > I've not tried installing whatever package contains, say,
> > pg_test_timing,
>
> (postgresql95-contrib)
>
> > but it would be nice if all the PG upstream RPMs "did the right
> > thing" with respect to alternatives and "just worked'.
>
> We made this design decision a few years ago, and I'm open to any
> solutions / suggestions that won't break the multiple version
> installation feature.

Because RH has `alternatives` perhaps the thing to do is to talk
to the debian packagers and adopt a consistent cross-distro policy.
I've never had any trouble with multiple PG versions on debian; I've
never had to think about it.  So they must be doing something right.

I have cc-ed the debian pg packagers.  Perhaps they can describe
their magic formula.  I always assumed it was that I could enable
any version of pg I wanted using alternatives but come to think of
it I don't believe I ever have.  Maybe I don't do enough work with
multiple pg versions and have simply gotten lucky.  Regardless,
all the binaries seem to be in my $PATH whenever I need them.

For more PG debian packager contact info see the CONTACT:People
section of: https://wiki.postgresql.org/wiki/Apt

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein