apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [MAINTAINER] devel/apr-gdbm-db42: apr-util 1.3.7 breaks dbd support
Date Tue, 09 Jun 2009 17:12:16 GMT
Joe Orton wrote:
> On Tue, Jun 09, 2009 at 10:58:24AM -0500, William Rowe wrote:
>> Joe Orton wrote:
>>> On Tue, Jun 09, 2009 at 09:03:16AM -0500, William Rowe wrote:
>>>> As a packager, I can see how you might view 1.3.4-> as a minor version
>>>> but from the perspective of any user deploying a package linked against
>>>> 1.3.4 and migrating to 1.3.7, no packages need to be recompiled.  That is
>>>> binary compatibility.
>>> This is a source compatibility issue though, just as it was when the 
>>> LDAP buildfoo was broken in the same way.
>> No; the dbm and dbd are complete abstractions.
> You can't come along after the fact and draw compatibility lines 
> wherever you please.

Then we freeze the code and correct no bugs, because every user exploiting
a bug is potentially the user of a feature.  DBM was abstracted by Greg and
Ryan to avoid *exactly* this problem, long before apr-1.0.0 shipped.

There is nothing in the autodocs suggesting that any dbm or dbd API are
valid apr_util calls.  That is as opposed to the incomplete ldap interface,
which we agree is bogus.

> APR-util has historically exported the DB library dependency.  
> Applications depend on this.  It is part of the build API -- e.g. 
> `apu-N-config --db-version` has no purpose otherwise.
> Breaking the exported dependency breaks source backwards compatibility.

Then vote for [one of] Bojan's patches.  I like the second one better,
having reviewed them both.  We'll undo this mess entirely in 2.0.

Bojan's patch restores the autogunk behavior to 1.3.8-dev quite effectively,
IMHO.  And I'm voting 0 because we disagree on this assessment, but I'm not
holding up improvements of compatibility if others believe that they are,
in fact, improvements.  The patch appears technically correct.

>>> Also I can't see that the threadsafety issues in the DBM DSO-ification 
>>> was ever resolved, am I missing something?
>> You are not missing anything, and solutions are welcomed.  This was not
>> unique to dbm (or ldap), it existed since 1.3.0 for dbd.
> The DBD API was written with an explicit process-global initializer, so 
> it is not correct that the same problem exists there.  I haven't looked 
> at the LDAP crap.

The obvious answer "was" apr_util_init() which would have been feature
agnostic, rather than apr_dbd_init.  In fact, apr_dbd_init() will cause
the entire dso structure for dbm, ldap etc to be initialized, avoiding
the race.

A programmatic solution is to initially apr_dbm_open() (or _open_ex) the
desired database, confirming that it is present or needs to be created
before further operations.  This would be useful by most consumers in the
first place, to inform the user that the resource is not presence (thinking
in terms of mod_authn_dbm, etc, during the config phase).  Once initialized,
by any mechanism (dbd_..., dbm_..., ldap_..., etc) the race is silenced.

View raw message