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 09:24:39 GMT
On Fri, Nov 23, 2001 at 09:39:47PM -0800, Justin Erenkrantz wrote:
> On Thu, Nov 22, 2001 at 01:38:30PM +1100, Daniel Stone wrote:
> > On Tue, Nov 20, 2001 at 12:32:07PM -0800, Justin Erenkrantz wrote:
> > > [ Please inline your patches rather than attaching them unless
> > >   you are using LookOut!  It makes it awfully hard to review.  ]
> > 
> > What's LookOut! ? BTW, inlining is sorta tricky to do with mutt, and I
> > haven't yet mastered vim - it was easy with nmh, tho. :)
> Outlook.  (You have to LookOut! for Outlook as it isn't compliant
> with didly squat.)  I just insert the files into vi with :r.  

Aah, I see.

> > apache used to have a program called "ubersed", but we don't use that
> > any more as I think it's a crude hack - patches work just as well.
> Eh, what's that?

ubersed is still in the Debian apache sources to this day - it's just a
big chunk of sed to convert @@Prefix@@ etc, that you run every config
file, etc, through.

> > > No.  We want to be picky with our libtool version - the version we 
> > > built with (i.e. in build/) is the one want to use with 
> > > apxs-enabled builds.
> > 
> > Why's this?
> Libtool is a very tricky beast.  Oftentimes, we want a *very* specific 
> version on a system (the libtool in my path isn't necessarily the same
> one that I build with - this may cause trouble when building with apxs).  
> Also, consider OS/X.  You can't use the libtool in the PATH because it 
> isn't GNU libtool.  The only libtool we can rely on is the one in 
> build/libtool that we built in the build.  You guys are free to add
> this to your package, but I won't commit this back to the tree as it
> would break other platforms.

If the Debian libtool didn't work flawlessly for every platform we have,
we wouldn't have it in, it's that simple.

> > > > >>      - add a --with-ssl-port as we have --with-port
> <snip, snip>
> > > Commented on this yesterday.  I don't like this.
> > 
> > I didn't catch that one.
> The prevailing belief of the developers is that mod_ssl is too
> hard to automatically configure (I don't necessarily hold this
> position, mind you).  Therefore, we want the user to manually 
> configure it themselves.

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

> > A .spec file is what is used to build an RPM. Its format is fairly
> > self-explanatory, if (IMHO) on some very, very potent crack.
> I was asking about FHS.  I'm not sure how that has anything to do
> with changing stuff - why can't that just be a layout?

I'm not sure myself - the dpkg uses a layout.

> > My ServerRoot is /etc/apache2, but almost nothing uses that.
> >
> > sysconfdir is not respected, as the conf file is defined in
> > to be conf/$progname.conf.
> IMHO, --prefix is generally implied as the default binary path.
> --sysconfdir is where we should place config files.  But, I
> know we aren't handling that correctly.  But, our config
> layout has always been a bit messy.


> It may be worthwhile to step back and determine what the
> optimal layout is for each of you and see if we can support
> that out-of-the-box via config.layout.  -- justin

Feel free to talk to me about this - I'd be only too happy to respond.

Daniel Stone						    <>
<rcw> does anyone else think it's unhealthy for Overfiend to keep his feelings
to himself?

View raw message