Re: [GENERAL] A change in the Debian install

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