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

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:        

Hi,

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.

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 .

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.

Regards,
--
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

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

--
Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pkg-debian

Re: Karl O. Pinc 2016-08-30 <20160830080047.2a89b286@slate.meme.com>

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.

The SQL manpages are built as part of the stock documentation build.
"make -C doc man" and friends. They have much more content than "psql
\h".

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.

postgresql-common is also using update-alternatives to manage symlinks
to manpages (though less so for binaries). I believe what we do
differently is to use the "slave links" mechanism to manage a
gazillion of symlinks through one master, while the yum packaging uses
individual links.

I have cc-ed the debian pg packagers. Perhaps they can describe
their magic formula.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/

There's even a .spec file in there if you want to try it on RH :)

Christoph

--
Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pkg-debian