On Sun, Oct 10, 2004 at 01:48:39AM +0100, Philip Martin wrote:
> From
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275545
>
> > 1.1.0 have incompatible changes in the lib interface.
> >
> > | Starting web server: Apache2Syntax error on line 3 of /etc/apache2/mods-enabled/dav_svn.load:
> > | Cannot load /usr/lib/apache2/modules/mod_authz_svn.so into server: /usr/lib/apache2/modules/mod_authz_svn.so: undefined symbol: svn_config__enumerate_sections
>
> Are the Subversion ABI/versioning rules supposed to ensure that a
> 1.0.x mod_authz_svn.so work with 1.1.x libraries?
>
> On the 1.0.x branch r10357 uses a non-public symbol from libsvn_subr,
> namely svn_config__enumerate_sections, and that symbol is not present
> on the 1.1.x branch. If an third-party application did this we would
> claim that it was breaking the rules and could not expect such a
> symbol to be present in 1.1.x. Is mod_authz_svn allowed to get away
> with it because it is part of Subversion? If so we need to explain to
> distributers that they need to ensure that the 1.1.x libraries
> conflict with the 1.0.x modules.
IMHO, we should be telling people that all the libraries and the Apache
modules need to go together as a unit. I've always included a
requirement in my packages that required the same library versions as
the modules. As a result the only issue my packages ran into was that
Apache didn't get automatically restarted correctly because the new
libsvn_subr had not been installed by the time mod_dav_svn was installed
and tried to automatically restart Apache.
In the case of Debian, they don't have any such dependency. In my
opinion they really should. The person I spoke to on IRC and who I
believe filed the bug referenced above, indeed did want the 1.1.0
module.
That said... This particular case was done becasue of a security fix.
We needed that function. But it had to live in libsvn_subr because of
some need for some static functions. This left us in a bad spot as to
how to apply the fix. And this is what we agreed at the time was the
best solution.
This became a problem not because we used a private function in a
module. But because we then later removed the private function without
leaving a compatability stub for it. In the future when we backport a
fix that requires us to do something like that. We need to make sure
that future versions have both the new public and the old private
function.
Doing something as simple as this in 1.1.0 would have completely avoided
the issue:
Index: subversion/libsvn_subr/config.c
===================================================================
--- subversion/libsvn_subr/config.c (revision 11275)
+++ subversion/libsvn_subr/config.c (working copy)
@@ -647,6 +647,15 @@
int
+svn_config__enumerate_sections (svn_config_t *cfg,
+ svn_config__section_enumerator_t callback,
+ void *baton)
+{
+ return svn_config_enumerate_sections (cfg,
+ (svn_config_section_enumerator_t) callback, baton);
+}
+
+int
svn_config_enumerate_sections (svn_config_t *cfg,
svn_config_section_enumerator_t callback,
void *baton)
Index: subversion/libsvn_subr/config_impl.h
===================================================================
--- subversion/libsvn_subr/config_impl.h (revision 11275)
+++ subversion/libsvn_subr/config_impl.h (working copy)
@@ -157,6 +157,15 @@
const char *mode,
apr_pool_t *pool);
+
+/* Stubs for allowing 1.0.x Apache modules to be mixed with 1.1.x libraries. */
+typedef svn_boolean_t (*svn_config__section_enumerator_t)
+ (const char *name, void *baton);
+
+int svn_config__enumerate_sections (svn_config_t *cfg,
+ svn_config__section_enumerator_t callback,
+ void *baton);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 10 21:26:11 2004