[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] fix libsvn_auth_gnome_keyring.pc w/libsecret

From: Philip Martin <philip_at_codematters.co.uk>
Date: Thu, 03 May 2018 20:32:56 +0100

Joe Orton <jorton_at_redhat.com> writes:

> I thought about that, but the SVN buildsystem is building & installing
> them like libraries not like DSOs (which should be linked with libtool's
> -module argument and not installed directly in $libdir),

I suspect that is accidental. The RA/FS option --enable-dso, which
became --enable-runtime-module-search, was added a long time ago and the
names of the libraries/modules do not change when switching between
shared library and DSO. When the auth DSOs were added they just
followed the same naming scheme as the RA/FS DSOs.

> and there are
> symbols exposed in the headers like svn_auth_gnome_keyring_version().

I'm not sure why those functions are public, we should probably
deprecate them and make them private functions. I don't think a 3rd
party can do anything useful with the public gnome/kwallet API. Even a
3rd party implementing a custom auth provider would not use the
gnome/kwallet part of the svn_auth_ API.

> So it looks a bit weird if they are really not intended to be used as
> libraries?

Your patch is an improvement so I would be happy to see it on
trunk/1.10. Going further and removing some .pc files is probably also
suitable for 1.10. Changing the DSO names and installation location is
probably not suitable for 1.10.

Received on 2018-05-03 21:33:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.