httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: cvs commit: apache-1.3/src CHANGES
Date Wed, 11 Nov 1998 08:03:52 GMT

In article <36489A26.8940E468@algroup.co.uk> you wrote:
> Rodent of Unusual Size wrote:
>> Martin Kraemer wrote:
>> >
>> > I have the feeling that the main concern of Ken and you (and mine and
>> > Marc's, in part) are the fact that the default paths are different
>> > from the "standard" locations (/usr/local/apache/{conf,logs,htdocs}).
>> 
>> I have three concerns; two technical and one philosophical.
>> The technical concerns are the divergence of the paths and
>> the divergence of support (ref. this suExec change that
>> only works if you use configure).  The philosophical
>> issue is about the change of 'direction.'

> Quite - and I'm starting to find that other modules that used to "just
> work" with Configure now require hand-patching (and the supposedly
> better configure route requires a slew of command-line flags as long as
> your arm to just get you back to where you were before it was
> "improved").

Then those modules or you (the one who tries to use it) do it wrong. But it
doesn't mean APACI is wrong. Look at mod_ssl. It assumes to be used with
APACI, but runs fine with the old configuration way, too. How? It uses
variables from src/Configuration, that's all. Same for mod_perl, etc. This way
modules work with and without APACI. And I don't know any module which doesn't
work without APACI. So, please be more detailed here, Ben. What module makes
problems and _WHAT EXACTLY_ is the problem where you have to hand-edit
something?

> I also agree that --compat should be the default, and not be required to
> put things where almost everyone expects them to be 

Sorry, "almost everyone" is mainly Apache developers here. Others expect that
a "configure" script uses the paths they are used from "configure" scripts,
i.e. paths defined in the GNU standards. The only people who expect things in
other locations are those who think "configure" isn't GNU Autoconf-style.
That's all IMHO.

> (not forgetting that
> not using --compat doesn't just change absolute paths but also where
> things live relative to the server root and other completely arcane
> shit).

No, APACI maintains relative paths, too. It recalculates the relative paths
from the selected layout and builds Apache with it. Look inside configure,
please.

>> I'm most concerned about the technical issues.  ISTR the
>> path business was discussed madly with no change resulting,
>> but no resolution either.  But I'll need to review the
>> archives before I can comment intelligently on it anew.

> +1 to making the default _exactly_ the same as Configure. The hell with
> the archives.

Sorry, but then I'll vote -1. Making it totally similar to Configure makes new
confusion: First because people are already used to APACI's paths (harmless
problem) and second because a script named "configure" usually doesn't imply
Apache paths in the users mind (big problem).

I think the whole debate is based on a simple but wrong assumption about what
APACI resembles. It's named APACI which stands for "Apache Autoconf-style
Interface" and this implies that it resembles GNU Autoconf and the way people
are used to building a package with it. Making --compat the default creates a
lot of new confusion. I don't think this is really better.

Instead I think it's better to reduce the existing confusion a little bit by
first letting APACI adjust the paths in the htdocs files (so they match the
paths used under install time) and second to add a few more checks which make
sure the user doesn't mix the src/Configure and the configure way of building.
Then we have eliminated the two main confusion problems which occured on
c.i.w.s.u and the bugdb and haven't introduced new confusion. How about this?

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message