[Libreoffice] postresql-sdbc bits out of minutes of tech. steering call

[Lionel Elie Mamane]

On Mon, Dec 12, 2011 at 09:46:37AM +0100, Fridrich Strba wrote:
> On 12/12/11 08:14, Lionel Elie Mamane wrote:

>> I did that because it seemed the easiest thing to do at first
>> sight. However, we are losing the advantage of that, and thus I
>> propose we switch to dynamic linking, and bundling the lib on
>> platforms / situations that need it.

> Where are we actually losing the advantage?

Well, the advantage of linking statically is that we don't have to
bundle a shared library and muck with rpath&friends to have it found
at runtime. Is there another one I'm not aware of?

If we have to link dynamically against other libraries that we have to
bundle in the extension, then we have to do the rpath-thing anyway for
these other libs, and for N>0, doing it for N+1 libs is not more
difficult than doing it for N libs.

But indeed if we end up not shipping any extra shared library in the
extension (that is N=0), then indeed static linking is easier for us.

>>  - no SSL/TLS support, for encrypted communication with the DB server
>>    and authentication by X.509 certificate.

> We bundle OpenSSL with LibreOffice,

We do? Oh, great, I had missed that.

>> As an added bonus, this makes it easier for our users to upgrade the
>> libraries we link against (for bugfixes or new features in new
>> versions or ...): just overwrite the DLL/SO/DYLIB file with an
>> upstream-provided one (downloaded from http://www.postgresql.org).

> No, no, no! Then you will have a mix of environment that you don't
> know compiled with options that you cannot be sure about and you
> will have an unmaintainable code.

We will have (and ship) the code we compiled, with the options we are
sure about; if users overwrite our binaries with others, well, they
have what they put there. We leave them freedom to tinker more easily
(no need to recompile, just overwrite files), and yes, sometimes by
tinkering one breaks stuff. That's the nature of it.

>> This also means that by our "we have to build everything we ship"
>> rule, we have to internalise, according to my first quick survey:

>>  - MIT Kerberos:

> It should be possible to assume as a system library for Linux and
> MacOSX

OK, good.

>>  - Kerberos for Windows: that's not part of the OS -> internalise
>>    (http://web.mit.edu/kerberos/dist/index.html#kfw-3.2)

> Do we really really need this on Windows?

It depends what value we give to "really". My guess is that it is
desirable. Without it our internal libpq has one less feature. I don't
have a good idea of how significant that feature is, since Windows has
some Kerberos implementation, too; libpq (if compiled with support for
both) allows to choose which one to use at runtime. What are the
compared compatibility issues and/or features of both, I don't
know. For example, can the Windows Kerberos client authenticate
against all Unix Kerberos setups that MIT-Kerberos/GSSAPI can
authenticate against? I guess that if the PostgreSQL project went the
extra mile of allowing simultaneous support for both, selectable at
run-time and all that, this means at least some users benefit from it.

>>  - LDAP: We already have OpenLDAP-related stuff in configure.in... So
>>          can postgresql-sdbc just use that, or is the existing stuff
>> 	    "too optional"? I mean it seems to be replacing some Mozilla
>> 	    parts, not sure we enable it on our builds or if it just a
>> 	    service to distributions. If cannot just use:

>>    * MacOS X: is it bundled? Some googling finds LDAP-related commands
>>               in MacOS X 10.4, our baseline. So we are good to
>> 	         consider it a system lib?

>>    * GNU/Linux: Debian has stable soname since 2008. Assuming other
>>                 distros are similar, is that sufficient to consider it
>> 		a system library?

> So, in LibreOffice, we have two ways of use LDAP: Either we use the ldap
> functionality from the bundled mozilla, or we use OpenLDAP.

Yes, but libpq "as is" AFAIK cannot use Mozilla-LDAP. Maybe it can be
hacked to do that. Are OpenLDAP and Mozilla-LDAP API-compatible, so
that we can just use Mozilla-LDAP headers and libraries where libpq
assumes OpenLDAP, and not change anything the in the libpq sources?
Then I guess it would be easy enough indeed.

-- 
Lionel