Обсуждение: Re: [GENERAL] A change in the Debian install

Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> (But ... these statements are based on an assumption of out-of-the-
> box Postgres behavior.  I would not exactly put it past the Debian
> packagers to have decided to change this for reasons of their own,
> and their track record of telling us about such decisions is many
> miles south of abysmal.  So you might look at whatever patches
> are in the Debian package to see if there's anything touching
> pgstat.c's socket-setup logic.)

I don't believe this is really a fair assessment.  Maybe at some point
in the distant past, but not today.  Christoph is regularly on this list
contributing to threads regarding packaging, submitting patches of his
own for improvements to PG, and the patches currently included in the
Debian distribution, at least mostly, are for things which really should
be possible to do with configure options, but which we don't provide
today, or things we should just be handling already.

The non-comment/documentation patches include for the Debian PG 9.6
packages are:

50-per-version-dirs.patch
  Use version specific installation directories so that several major
  versions can be installed in parallel.  This includes changing
  pkglibdir and includedir_server.  Those might be able to be set
  through existing configure flags and that's probably something we
  could work with Christoph to do.  There's also a change to pg_config
  which might be a bit more difficult to handle in upstream (related to
  how pg_config ends up in /usr/bin, but that isn't the "right" BINDIR).

51-default-sockets-in-var.patch
  Use /var/run/postgresql/ for the DEFAULT_PGSOCKET_DIR.  We really
  should allow this to be changed in configure.

54-debian-alternatives-for-external-tools.patch
  Use 'sensible-editor' for DEFAULT_EDITOR, and 'pager' for
  DEFAULT_PAGER.  These could also be done through configure switches, I
  would think.

64-pg_upgrade-sockdir
  This is a bit of a curious one, the description is:
  Fix for: connection to database failed: Unix-domain socket path

"/build/buildd-postgresql-9.3_9.3~beta1-1-i386-mHjRUH/postgresql-9.3-9.3~beta1/build/contrib/pg_upgrade/.s.PGSQL.50432"
  is too long (maximum 107 bytes)

  See also: http://lists.debian.org/debian-wb-team/2013/05/msg00015.html

  This basically adds a mechanism to fall back to using /tmp if the
  socket path is too long.  Would probably be good to figure out a
  better way.

filter-debug-prefix-map
  Description: Remove -fdebug-prefix-map=/p/w/d=. from CFLAGS and
  CONFIGURE in pg_config. The embedded path makes the build
  non-reproducible, and the flag is useless for building extensions
  anyway.
  Not sure there's much we can do about this one, but it's also just for
  pg_config.

hurd-sem_init
  Adds -pthread to LIBS and forces POSIX semaphores on hurd.  I'm not
  sure if this is all still required, but if so, it'd probably be ideal
  if we could figure out a way to handle it automatically instead of
  making the Debian packagers have to do it.

In short, there's certainly nothing that touches pgstat.c's socket-setup
logic and almost all of the changes are just changes to #define's to
specify alternative paths or external tools.

I'll start a discussion with Christoph on if we might, already, be able
to remove some of these, and where we might be able to make upstream
changes to remove the need for others.

Thanks!

Stephen

Re: Magnus Hagander 2017-04-06 <CABUevEzkTLFSFZvCVsk07oEVgSZmWo9kPaGiJtrONYjQrH5PLw@mail.gmail.com>
> On Thu, Apr 6, 2017 at 3:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > > (But ... these statements are based on an assumption of out-of-the-
> > > box Postgres behavior.  I would not exactly put it past the Debian
> > > packagers to have decided to change this for reasons of their own,
> > > and their track record of telling us about such decisions is many
> > > miles south of abysmal.  So you might look at whatever patches
> > > are in the Debian package to see if there's anything touching
> > > pgstat.c's socket-setup logic.)
> >
> > I don't believe this is really a fair assessment.  Maybe at some point
> > in the distant past, but not today.  Christoph is regularly on this list
> > contributing to threads regarding packaging, submitting patches of his
> > own for improvements to PG, and the patches currently included in the
> > Debian distribution, at least mostly, are for things which really should
> > be possible to do with configure options, but which we don't provide
> > today, or things we should just be handling already.
> >
>
> +1. While this may have been true in a *very* distant past, it's certainly
> not anymore. So let's try to avoid spreading disinformation about that.
>
> And FWIW, the RPM distributions have about the same number of patches...

Thanks Stephen and Magnus. I don't think the way Martin and I have
been handling the Debian packages over the last year deserves being
bashed that loudly. At least I would expect a Cc on such matters, Tom
should know very well whom to address here.

> > 51-default-sockets-in-var.patch
> >   Use /var/run/postgresql/ for the DEFAULT_PGSOCKET_DIR.  We really
> >   should allow this to be changed in configure.
>
> This looks exactly like something the RPMs want as well, so we should
> definitely look at providing that upstream.

That one is touching src/include/pg_config_manual.h only, i.e.
something that is actually meant to be altered.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/51-default-sockets-in-var.patch?h=10

> I'll start a discussion with Christoph on if we might, already, be able
> > to remove some of these, and where we might be able to make upstream
> > changes to remove the need for others.
>
> That'd be useful. I think you should also include Devrim to figure out what
> things would actually make *both* sides happier.

Aye.


Re: Stephen Frost 2017-04-06 <20170406134629.GT9812@tamriel.snowman.net>
> The non-comment/documentation patches include for the Debian PG 9.6
> packages are:
>
> 50-per-version-dirs.patch
>   Use version specific installation directories so that several major
>   versions can be installed in parallel.  This includes changing
>   pkglibdir and includedir_server.  Those might be able to be set
>   through existing configure flags and that's probably something we
>   could work with Christoph to do.

Nod. If someone figures how to translate that to configure (or
possibly make) arguments, I'd be happy to move to using that.

>   There's also a change to pg_config
>   which might be a bit more difficult to handle in upstream (related to
>   how pg_config ends up in /usr/bin, but that isn't the "right" BINDIR).

pg_config is special there, because we ship it twice, once in
/usr/bin/ libpq-dev, and then again in
/usr/lib/postgresql/$version/bin/ from postgresql-server-dev-version.
Not sure if there's a saner approach that still allows co-installation
of multiple versions, while still supplying a pg_config from libpq-dev
that allows using --includedir and other version-independent queries.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/50-per-version-dirs.patch?h=10

> 54-debian-alternatives-for-external-tools.patch
>   Use 'sensible-editor' for DEFAULT_EDITOR, and 'pager' for
>   DEFAULT_PAGER.  These could also be done through configure switches, I
>   would think.


https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/54-debian-alternatives-for-external-tools.patch?h=10

> 64-pg_upgrade-sockdir
>   This is a bit of a curious one, the description is:
>   Fix for: connection to database failed: Unix-domain socket path
>
"/build/buildd-postgresql-9.3_9.3~beta1-1-i386-mHjRUH/postgresql-9.3-9.3~beta1/build/contrib/pg_upgrade/.s.PGSQL.50432"
>   is too long (maximum 107 bytes)
>
>   See also: http://lists.debian.org/debian-wb-team/2013/05/msg00015.html
>
>   This basically adds a mechanism to fall back to using /tmp if the
>   socket path is too long.  Would probably be good to figure out a
>   better way.

That one is actually on my TODO list:
https://www.postgresql.org/message-id/20140711094009.GB3115%40msg.df7cb.de
I'll need to restart working on it.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/64-pg_upgrade-sockdir?h=10

> filter-debug-prefix-map
>   Description: Remove -fdebug-prefix-map=/p/w/d=. from CFLAGS and
>   CONFIGURE in pg_config. The embedded path makes the build
>   non-reproducible, and the flag is useless for building extensions
>   anyway.
>   Not sure there's much we can do about this one, but it's also just for
>   pg_config.

I hope to be able to drop this one again. There is a patch for gcc in
preparation that will allow using a constant -fdebug-prefix-map=
compile flag that doesn't embed the current build directory:

https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_path_issue.html

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/filter-debug-prefix-map?h=10

> hurd-sem_init
>   Adds -pthread to LIBS and forces POSIX semaphores on hurd.  I'm not
>   sure if this is all still required, but if so, it'd probably be ideal
>   if we could figure out a way to handle it automatically instead of
>   making the Debian packagers have to do it.

This one is already gone again for the 10 packaging. The 9.6 version
is:

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/hurd-sem_init

> In short, there's certainly nothing that touches pgstat.c's socket-setup
> logic and almost all of the changes are just changes to #define's to
> specify alternative paths or external tools.

I don't have an answer the OP's question. My bet would be on
"localhost" resolving to something weird.

Christoph