On Friday 17 August 2001 22:57, Justin Erenkrantz wrote:
> On Fri, Aug 17, 2001 at 10:26:32PM -0700, Ryan Bloom wrote:
> > I just noticed this.
> >
> > > Log:
> > > Fix --enable-modules=all breakage with mod_auth_db and mod_auth_digest
> > > by allowing a module to disable itself if its prerequisites are not
> > > met.
> > >
> > > This introduces the subtle nuance that if you request a module and you
> > > don't meet its prerequisites, it'll refuse to build itself.
> > >
> > > mod_ssl exits if its prerequisites are not met.
> >
> > -1. If I enable a module, I want that module. If it can't be
> > configured, then we should print an error message, and exit the
> > configuration. I will not move these changes forward, and this should be
> > backed out before 2.0.25.
>
> It is implicitly enabled via --enable-modules=all. The user did not
> specify that they wanted these modules exactly. I posted a message
> asking if we should only disable it if the user did not explictly
> request it and error out if they did explictly request it. Should
> this be our behavior instead?
If the user says, "--enable-modules=all", then the user has said, "I want
ALL of the modules in the server". We have just disabled that, because
now even if I ask for all modules, I won't get them all. That is bad.
> The situation before this commit was that on almost all platforms,
> --enable-modules=all configuration was broken because mod_auth_db
> and mod_auth_digest would be enabled at configure time. However,
> compilation would fail because of failed dependencies. -- justin
Then we should fix the modules, and learn to find the dependancies
correctly, or if we can not find the dependancies, then we should exit
out of the configure step with an error. Then, the user is informed up front
that we aren't able to configure their chosen modules, and they can either
install the items they need, or they can disable that module.
As things stand now, we are failing silently. Failing silently is _always_ the
wrong solution.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
