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
Received on Sun Oct 10 18:12:20 2004