You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2004/10/10 00:48:39 UTC
An ABI problem in mod_authz_svn?
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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: An ABI problem in mod_authz_svn?
Posted by Ben Reser <be...@reser.org>.
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 <be...@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
Re: An ABI problem in mod_authz_svn?
Posted by Erik Huelsmann <e....@gmx.net>.
> On Sat, 2004-10-09 at 20:48, Philip Martin wrote:
> > 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.
>
> The logic we applied (at my urging) is that we should feel free to use
> internal symbols between libraries when necessary, because we have no
> reason to expect that users won't have a matched set of libraries and no
> reason to want to make that work. We didn't consider the logistical
> issue that people might upgrade the libraries without upgrading the
> httpd modules. (Or downgrade them, within a particular x.y line.)
>
> I tend to believe that if someone misses the httpd modules in an upgrade
> or downgrade, it was probably by mistake, and it's almost better that we
> catch the mistake than not (though an obscure linking error is not the
> best way to do so). But perhaps we should consider the httpd modules to
> be like applications, and make them follow the strict rules as if they
> were external programs.
Packagers have started to package mod_dav_svn as 'the Apache extension which
turns your Apache into a Subversion server'. Not as integral part of
Subversion packages, but more or less as a separate option.
In IRC I saw people upgrade to svn 1.1 and after discovering the perf hit
explicitly downgrading just mod_dav_svn. Obviously they don't think of it
as intergral part of Subversion. Which seems logical the way it is
currently being packaged.
> Another reason not to have this class of Subversion-private (but not
> library-private) symbols is that it means we can't use platform-specific
> mechanisms for protecting the library symbol namespace. So perhaps we
> should wean ourselves of the practice, although it does give us a lot of
> latitude at times.
Might help to prevent future problems, although we'd be making things hard
on ourselves...
bye,
Erik.
--
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: An ABI problem in mod_authz_svn?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-10-09 at 20:48, Philip Martin wrote:
> 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.
The logic we applied (at my urging) is that we should feel free to use
internal symbols between libraries when necessary, because we have no
reason to expect that users won't have a matched set of libraries and no
reason to want to make that work. We didn't consider the logistical
issue that people might upgrade the libraries without upgrading the
httpd modules. (Or downgrade them, within a particular x.y line.)
I tend to believe that if someone misses the httpd modules in an upgrade
or downgrade, it was probably by mistake, and it's almost better that we
catch the mistake than not (though an obscure linking error is not the
best way to do so). But perhaps we should consider the httpd modules to
be like applications, and make them follow the strict rules as if they
were external programs.
Another reason not to have this class of Subversion-private (but not
library-private) symbols is that it means we can't use platform-specific
mechanisms for protecting the library symbol namespace. So perhaps we
should wean ourselves of the practice, although it does give us a lot of
latitude at times.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: An ABI problem in mod_authz_svn?
Posted by Ben Reser <be...@reser.org>.
On Mon, Oct 11, 2004 at 05:24:25PM +0100, Philip Martin wrote:
> We could add the missing symbol to the 1.1.x ABI. It doesn't need to
> appear in a header file, a forwarding function in the library source
> alone would do. I don't know whether we should do this, just that we
> could do it.
ABI wise yes it doesn't need to be in the header. But source
compatability wise it would...
--
Ben Reser <be...@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
Re: An ABI problem in mod_authz_svn?
Posted by Philip Martin <ph...@codematters.co.uk>.
Erik Huelsmann <eh...@gmail.com> writes:
> As things are now, I think there is nothing we can do about it.
We could add the missing symbol to the 1.1.x ABI. It doesn't need to
appear in a header file, a forwarding function in the library source
alone would do. I don't know whether we should do this, just that we
could do it.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: An ABI problem in mod_authz_svn?
Posted by Erik Huelsmann <eh...@gmail.com>.
> 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.
I have already seen installs break because we decided that we could do
this. Even tried to work out some of those in irc.
As things are now, I think there is nothing we can do about it. But I
do think it was a mistake to use internal symbols in mod_dav_svn.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org