} libs ({n}={2,3,4}) if found.
> The patch tries to fall back to the old individual tests if the table
> driven algorithm fails, so should not have a negative impact (except on
> running time).
>
> Feedback welcome. Without the patch (at least without the 1st part)
> Apache-1.3 fai
individual tests if the table
driven algorithm fails, so should not have a negative impact (except on
running time).
Feedback welcome. Without the patch (at least without the 1st part)
Apache-1.3 fails to compile mod_auth_db on Solaris with libdb4 installed.
Martin
--
<[EMAIL PROTEC
We now have three votes for removing mod_auth_db in STATUS
(me, Ian, and Lars).
All of its functionality should have been merged into mod_auth_dbm.
Is there any further reason to keep it around?
Barring someone's veto, I'll axe it next week. -- justin
d what the type should be (config
> directive? tell apr_dbm_open() to autodetect?), then mod_auth_db
> becomes truly redundant.
>
> (expecting sanity checking of this :) )
>
Good Point -
OtherBill had mentioned there might be a patch to build *all* possible dbs
into apr, then let yo
rewritten to simply just use apr_dbm for everything...
>
> If my understanding is correct, mod_auth_db was there to allow you
> to force berkeley db on platforms where it is not the default dbm..
> If thats the case, it should now be obsolete since you can compile
> mod_auth_dbm
ng is correct, mod_auth_db was there to allow you
to force berkeley db on platforms where it is not the default dbm..
If thats the case, it should now be obsolete since you can compile
mod_auth_dbm against whatever apr dbm backend you choose.
sterling
On Thu, 15 Nov 2001, Cliff Woolley
Somebody please remind me what the plan is with mod_auth_db... will the
apr-util dbm stuff make it obsolete (ie, all you need is mod_auth_dbm)?
If so, to what extent are those changes included in 2.0.28?
Thanks,
--Cliff
--
Cliff
