Re: uuid-ossp (Re: [pgsql-packagers] Postgresapp 9.4 beta build ready)

Christoph Berg <cb(at)df7cb(dot)de> writes:
> [redirecting to -hackers]
> Re: Tom Lane 2014-05-15 <31008(dot)1400180005(at)sss(dot)pgh(dot)pa(dot)us>
>> Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com> writes:
>>> Yes, Jakob is right. On 9.4, we had to patch configure script along with
>>> uuid-ossp.c to resolve the uuid issue.

>> I think we need to discuss this on the open pgsql-hackers list.
>> It seems like we have to either
>>
>> (1) hack both configure and uuid-ossp.c to work around the issue
>>
>> (2) do something more radical, like adopt Palle's patch to use the
>> BSD uuid functions.
>>
>> Now, (2) sounds a bit scary for a post-beta1 change, but on the other hand
>> we know that ossp-uuid is a train wreck in progress. Maybe it's time
>> to do something about it. But that's got to be debated on -hackers not
>> here.

> Fwiw, libossp-uuid is the only non-trivial dependency of
> postgresql*.{deb,rpm} - I've been to trainings at customer sites more
> than once where we just had a preinstalled Linux machine with no
> internet and a set of PostgreSQL packages that needed dpkg
> --force-depends or rpm --nodeps to install just because the -contrib
> package needs that lib.
> So if we got rid of that dependency, life might become a bit easier
> also in that setting.

I was intending to draft something more self-contained to present to
-hackers, but since this is where we're at ... the quoted material
omits a couple of important points:

(1) People had been working around uuid-ossp's issues on OS X by
patching a "#define _XOPEN_SOURCE" into contrib/uuid-ossp/uuid-ossp.c.
As of 9.4 this is no longer sufficient because we upgraded to autoconf
2.69, which uses stricter testing for include-file validity than older
versions did. The test to see if uuid.h is available therefore fails,
unless that #define is also patched into the configure script. In any
case "#define _XOPEN_SOURCE" has enough potential implications that
this doesn't seem like a very recommendable solution.

(2) "Palle's patch" mentioned above can be seen here:
http://svnweb.freebsd.org/ports/head/databases/postgresql93-server/files/patch-contrib-uuid?revision=348732&view=markup
Basically it jacks up contrib/uuid-ossp and rolls the BSD uuid functions
underneath. It looks like this is based on work by Andrew Gierth.

So, having seen that proof-of-concept, I'm wondering if we shouldn't make
an effort to support contrib/uuid-ossp with a choice of UUID libraries
underneath it. There is a non-OSSP set of UUID library functions
available on Linux ("libuuid" from util-linux-ng). I don't know whether
that's at all compatible with the BSD functions, but even if it's not,
presumably a shim for it wouldn't be much larger than the BSD patch.

A bigger question is whether there are any user-visible functional
incompatibilities introduced by depending on either of those libraries
instead of OSSP uuid. Some research would be needed.

It's not exactly appetizing to consider fooling around with such changes
post-beta1. But on the other hand, OSSP uuid *is* a train wreck in
progress, and remaining dependent on it for another release cycle is not
exactly appetizing either.

Comments? Is anybody feeling motivated to do the legwork on this?

regards, tom lane