----- Original Message ----- > Fred Moyer <f...@redhotpenguin.com>: > > > > 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.
Great news! Fedora is using httpd24 branch and I know some people using it in their projects with httpd-2.4 without any problems. I'm more than happy to apply patches to the httpd24 branch if you don't have commit access there. I will try to re-merge current trunk with httpd24 branch soon - today or on Monday (I have done that some months ago for last time). > 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. I think what we are lacking here right now is some sort of decision what to do next. I can't decide which way should the development go, I don't have permissions (politically, not technically) to commit to trunk and so on. > 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. This is temporary state and it was supposed to be like that only before someone from core mod_perl developers decides how to continue with the development... As I said before in this email, I will re-merge httpd24 branch and if we decide to choose this way, I think I would be able to merge it regularly. > Would there be separate releases for 2.0.9 and 2.0.9-httpd24 ? I think we will have to support both for some time, so yes. The problem could be that some aspects of -httpd24's API differs from httpd22's 2.0.9. Technically this means that we would be providing two different versions, so maybe we could even number them differently, like 2.0.9 and 3.0.9? Both would share the same base code, but the latter one would be tweaked for httpd24. I'm not sure it's good idea, it was just something I had in my mind. > > 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. Hm, yes, they would need to generate for both versions, which could be tricky, because you can't have both httpd versions installed at the same time. On the otherside, I'm not sure there will be some case when xs has to be regenerated for both 2.2 and 2.4. All the important variables are already wrapped for 2.2 and since I read this list (1.5 years), I haven't seen such activity. So I think this is not so problematic. Developers working with httpd-2.4 will likely change only httpd-2.4 related xs files without touching httpd-2.2 versions. > How was this handled for the Apache 2.0 -> 2.2 changes? Are there just > more API differences in 2.4? That's question for someone who was here when this migration happened... > > 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. Right, in Fedora I've been doing that for some time, but when I committed my patchset to httpd24 branch, I have found out this is not good for end users, because parsing system headers tends to be error-prone. But if you build in stable environment, it's not problem to tweak the parsing to ignore right headers and make this way working. It's just not the way of building I would support globally. > -- > Niko Tyni nt...@debian.org > Regards, Jan Kaluza --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
