perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niko Tyni <>
Subject httpd24 (was Re: 2.0.9-dev)
Date Fri, 21 Jun 2013 08:20:38 GMT
Fred Moyer <>:

> > What else? Time for 2.4 httpd?

Debian is also moving to Apache 2.4 and we've been working on getting
mod_perl2 to cope. We're currently using the httpd24 branch as a base
(thanks for your work, Jan!), merged with the 2.0.8 release. We found
a few issues that I intend to post as separate patches / reports soonish,
but we've generally got it working now. 

On Fri, Apr 19, 2013 at 02:22:25AM -0400, Jan Kaluza wrote:

> I think we have to create new mod_perl row for httpd24 or change the build
> process.

FWIW I'd be willing to help here too (as time permits), but I'm not
really familiar with the build process. Opinions and advice from more
experienced mod_perl developers would be welcome.

Selectively quoting the options you listed:

> a) have two branches - trunk and httpd24 (analogy to httpd-trunk and httpd-2.4).

I think this is clearly not optimal in the long term, but if it is how
things are going to be, maybe SVN merges would help to avoid committing
everything twice.

At the moment httpd24 is lagging behind trunk. There seems to be a need
for making sure they stay synchronised.

Would there be separate releases for 2.0.9 and 2.0.9-httpd24 ?

> b) have just trunk for both httpd24 and httpd22 code
> I don't know XS well, but if you think it's easy enough to change build to use different
> xs directory (or its subset) for 2.4 and different for 2.2, then I think this is way
to go.

As I understand it, this has the drawback that a developer changing an
xs map needs to have access to both 2.2 and 2.4 to run 'xs_generate'
for both. But I guess they'd have to have that anyway for testing.

How was this handled for the Apache 2.0 -> 2.2 changes? Are there just
more API differences in 2.4?

> c) merge just httpd24 .c/.h changes to trunk and let the users/devs to run make xs_generate
> themselves and try to fix the /usr/include/ parser to be more reliable. 

For the purposes of Debian alone, I think c) would be adequate (we
probably could and should make sure xs_generate works there), but
I agree b) is generally better for end users.
Niko Tyni

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message