httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Proposal: Future release strategies
Date Thu, 06 Sep 2001 16:42:59 GMT
Ryan Bloom wrote:

> We have no control over APR.  APR will not make a release just because
> the web server wants it to.  Apache needs to either use an already released
> APR, or it needs to specify a date/time to check out APR.

We have no control over libc either, and yet we use that. Surely we can
just consider APR a necessary external library that we link against -
which has it's own release schedule - or is APR still too closely tied
up with Apache for this to be practical? 

> > o Each of mod_ssl, mod_proxy and mod_ldap needs to be stripped into it's
> > own archive, and the rollup script needs to be modified to produce a
> > rollup tarball for these modules (or combined module).
> 
> Woah.  Mod_ssl was put into the core for a reason.  I don't want to remove it
> unless everybody wants to.

I included it here because people mentioned that there were potential
import/export problems still in some parts of the world. It's not that
critical either way - in fact it is much more convenient if it is
included inside the core.

>  I am not sure that I even believe mod_ldap should
> be a sub-project either.  I don't remember ever having that conversation.  But,
> I will not stand in the way of it.

Well - the vote on the table is to take the LDAP code out of Apache v2.0
- but the next question is when it's removed, what do we do with it? I'm
not keen on seeing it sit in limbo like mod_proxy has been for a while,
which is why I would like to see something resolved on the rollup issue.

> > o The build procedures for mod_ssl, mod_proxy and mod_ldap need to be
> > modified so that they are buildable outside the Apache tree.
> 
> No.  They should use the config.m4 mechanism.  We are releasing them as
> source, and they can easily be built inside the tree.  What's more, we can
> easily use apxs to build them outside the tree.

*We* could do these things easily, but I am thinking about the end user.
When they download something they expect to get a tarball, open it up,
go ./configure ; make ; make install. If all the ./configure script does
is locate apxs and installed apache headers and builds the source that
way that's fine - but we need to follow the path of least astonishment
for the users.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."
Mime
View raw message