Distributing httpd-2.2, redux
We've brought this up before and it sure didn't seem clear that we are all of one mind on the issue (and the last opinions were registered quite some time ago.) We've agreed that httpd won't be tagging it's own apr, we will release based on some minimum version (major.minor - since .subversion of apr must remain binary forwards backwards compatible from x.y.0 to x.y.n). Right now for 2.1-dev that's 1.2, and might end up 1.3. or even 2.0 when we are ready to declare httpd 2.2.0-GA. We've agreed that httpd can pick up an installed apr (provided the minimum version requirement is met.) Likewise, apr and apr-util have decided to pick up system iconv and expat. (We shouldn't do that to GNU libiconv without explicit decision by the user, but if it's the GNU iconv bundled in libc.so - then it's bound by the same libc exception clause.) I don't know what httpd does w.r.t. pcre offhand. On Win32 we've shipped httpd-2.0 source bundles with apr-iconv, while on unix distributions we simply choke on enabling apr_xlate() and the mod_charset_lite build. So where do we stand? * Ship httpd-2.2.x.tar.gz without apr? Then also drop pcre. It seems that apr would equivilantly drop expat/iconv. * Ship httpd-2.2.x.tar.gz with a specific apr? Then bundle expat, pcre, and iconv? One interesting synthisis we came up with on the #apr channel... what if the desires/needs of both packaging folks (who want individual components) and end users building from scratch could both be met? * Ship httpd-2.2.x.tar.gz (solo), and httpd-2.2.x-bundle.tar.gz which includes all the sub-packages the user should likely need (including pcre/apr/-util/expat/-iconv/)? Perhaps even zlib/openssl? Well there's the question, should we try to serve both, or argue over which bits are bundled and which the user obtains/installs seperately. Comments? Bill
Re: Distributing httpd-2.2, redux
--On September 30, 2005 1:43:50 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: * Ship httpd-2.2.x.tar.gz (solo), and httpd-2.2.x-bundle.tar.gz which includes all the sub-packages the user should likely need (including pcre/apr/-util/expat/-iconv/)? Perhaps even zlib/openssl? IIRC, Subversion has already decided to go down this path for it's upcoming 1.3.0 series. So, I'm not adverse to this idea for httpd either. It offers a compromise solution for our users - at the expense of some additional mirror space. We'd have to be careful to document what's what too so our users don't get confused by the additional options. (I would be against distributing anything beyond our 'bare' minimums - so no zlib or OpenSSL.) My only comment about unbundling pcre is that we're *very* particular about the pcre version. Most OS distribution's versions of pcre aren't even close to being acceptable. We can't rely on any OS-native regex engines either as they aren't sufficient. For expat and iconv, any installed version will likely be satisfactory. So, I think pcre must stay. -- justin
Re: Distributing httpd-2.2, redux
Justin Erenkrantz wrote: (I would be against distributing anything beyond our 'bare' minimums - so no zlib or OpenSSL.) I'll agree on the openssl count, although we really are only supporting later 0.9.6/0.9.7 and focusing on 0.9.8. But given how lightweight zlib is, and how much of a moving target it was before 1.2.3, I'd strongly argue that 'deflate' is a core feature, that if we teach httpd to 'reinflate' there are many old vulnerabilites that we expose our users to, and that shipping 1.2.3 would add very little pain for much mod_deflate gain. My only comment about unbundling pcre is that we're *very* particular about the pcre version. Then we should scream loudly if they don't grab the -bundle package that their system pcre is quite crufty and can't be used?
Re: Distributing httpd-2.2, redux
William A. Rowe, Jr. wrote: Justin Erenkrantz wrote: [..cut..] My only comment about unbundling pcre is that we're *very* particular about the pcre version. Then we should scream loudly if they don't grab the -bundle package that their system pcre is quite crufty and can't be used? As far as I understood Justin, most OS'es do not deliver a usable pcre version (cannot judge this myself). So if most users are forced for that reason to download the bundle tar ball I think the whole split in two tar's does not seem to make sense. So I guess pcre should stay coupled with the core httpd tar bundle and everything else can be moved to the bundle tar ball. Regards Rüdiger
Re: Distributing httpd-2.2, redux
William A. Rowe, Jr. wrote: But given how lightweight zlib is, and how much of a moving target it was before 1.2.3, I'd strongly argue that 'deflate' is a core feature, that if we teach httpd to 'reinflate' there are many old vulnerabilites that we expose our users to, and that shipping 1.2.3 would add very little pain for much mod_deflate gain. it might be worth turning mod_deflate on by default. there are still too many sites out there that do not have it on.
