httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Stone <>
Subject Re: Apache 2.0.27 and 2.0.28 RPM available
Date Sat, 24 Nov 2001 10:32:10 GMT
On Sat, Nov 24, 2001 at 02:12:51AM -0800, Justin Erenkrantz wrote:
> On Sat, Nov 24, 2001 at 08:24:39PM +1100, Daniel Stone wrote:
> > If the Debian libtool didn't work flawlessly for every platform we have,
> > we wouldn't have it in, it's that simple.
> We (as the Apache Group) can't make the assumption that every 
> OS knows what they are doing.  What you guys should probably do 
> is *always* run ./buildconf to ensure that your libtool version 
> overrides whatever one we distribute.

A quick look at debian/rules would confirm that we indeed do run
./buildconf every time.

> We're going to try to make 
> the decision that is best across all platforms - which is to 
> recommend using the one we provide in the release tarball.  In your 
> situations (both you and Henri), your libtool is known to be 
> better - so, just do ./buildconf and it'll magically be identical 
> to the one you have in your path.  =)

Heh. :)

> > Hm, well I just shang it on 443 regardless. Should add some Debconf
> > stuff to make this configurable. But at this stage, if the user says yes
> > to SSL support and then enables that host, SSL support is almost up and
> > happening - all the need to do is generate the certs (must write a
> > script to do this).
> Very nice feature.  However, Debconf isn't portable (is it?).  =)

I don't see any reason why it shouldn't be, although it probably depends
on Debian structures and stuff. It is written in Perl, so it shouldn't
be too tricky, although the quality of joeyh's crack is legendary within
Debian, soooo ... :)

> Ideally, we *would* have it so that we can have them make choices
> at compile-time, but there really isn't a nice way to do that.
> So, we rely on docs.


> Okay.  Here are the config.layout fields:
>     prefix, exec_prefix, bindir, sbindir, libexecdir, mandir,
>     sysconfdir, datadir, installbuilddir, errordir, iconsdir, htdocsdir,
>     manualdir, cgidir, includedir, localstatedir, runtimedir,
>     logfiledir, proxycachedir
> Now for the question that Henri brought up - is ServerRoot 
> sysconfdir?  I think we could make a case that ServerRoot is 
> prefix, but that httpd itself would know to look in 
> sysconfdir/httpd.conf for the config file and that we teach
> httpd.conf about the various location of things (like iconsdir,
> htdocsdir, etc, etc, etc).
> So, what's wrong with that?  We have a bunch of relative paths flying 
> around in our config file all keyed off of ServerRoot.  That's nice
> if you use our layout (which has everything as a descendant of 
> prefix), but horrific once you think differently than us.  So, maybe
> httpd-std.conf needs to be redone to handle all of the layout stuff.


> This gets me down a road that sounds like someone with commit 
> access may veto.  So, I'll leave it at this for now and try to 
> solicit feedback.
> Just to give you an idea of my ideal configuration:
> ./configure --prefix=/pkg/httpd-2.0.28 \
>     --sysconfdir=/etc/pkg/httpd-2.0.28 \
>     --localstatedir=/var/pkg/httpd-2.0.28
> It almost seems as if we have too much flexibility.  No way am 
> I going to type this:
> ./configure --prefix=/pkg/httpd-2.0.28 \
>     --sysconfdir=/etc/pkg/httpd-2.0.28 \
>     --localstatedir=/var/pkg/httpd-2.0.28 \
>     --iconsdir=/var/pkg/httpd-2.0.28/icons \
>     --errordir=/var/pkg/httpd-2.0.28/errors \
>     --htdocsdir=/var/pkg/httpd-2.0.28/htdocsdir \
>     --logfiledir=/var/pkg/httpd-2.0.28/logs \
> Yes, I can do this.  But, that's way too specific and as an
> admin, I think we need better default groupings (i.e. localstatedir
> consists of X, Y, Z).  -- justin


:) d

Daniel Stone						    <>
<rcw> bournemouth would, of course, be next to scaldinghotcoffee

View raw message