httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: cvs commit: apache-1.3/src CHANGES
Date Wed, 11 Nov 1998 22:12:57 GMT
Ralf S. Engelschall wrote:
> 
> 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 seem to remember it was mod_perl that I had a problem with lately.

> > 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.

Exactly, that's the problem - the relative paths are changed by APACI,
so if I build without --compat, and then do httpd -d /my/config/dir it
_doesn't work_. This comes as a big surprise to me, and no doubt to
anyone else used to the way Apache lays stuff out. Even worse, there's
no obvious docco for where everything should go, and even less obvious
reason why it should do this to me.

> 
> >> 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).

Most packages don't have much dependency on relative paths. AFAIK, using
configure doesn't give you many expectations about how relative paths
should behave. OTOH, experience with Apache does, and APACI screws those
expectations up royally. I'm often having to say "yes, I know it all
went weird, just do ./configure --compat and it'll all be back the way
you expected. Or, better yet, don't use configure at all."

> 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.

I don't care what its name means - it creates a support headache. That's
the problem.

> 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?

Arg. Adjusting docs does not adjust people's experience or expectations.
Mixing Configure and configure should be possible, or the claim that
configure doesn't affect the old way of doing things is void.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author     http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache/

Mime
View raw message