Re: A change in the Debian install

Re: Magnus Hagander 2017-04-06 <CABUevEzkTLFSFZvCVsk07oEVgSZmWo9kPaGiJtrONYjQrH5PLw(at)mail(dot)gmail(dot)com>
> On Thu, Apr 6, 2017 at 3:46 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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(dot)GT9812(at)tamriel(dot)snowman(dot)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