On 05.02.2013 23:12, William A. Rowe Jr. wrote: > The 2.2 builds all used OpenSSL 0.9.8 and that's where I would leave > it, while 2.4 builds aught to use 1.0.1.
+1 > That, and libxml2 and lua > are the packages we don't bundle. Those are additional 2.4 modules dependencies. +1 to bundle the latest libs in the first Windows binary release. For libxml2 later updates might always be able to go to the latest again, for Lua probably only minor updates are OK, because scripts may break. > But for the expat and pcre dependencies, the versions we shipped in > 2.2.23 and 2.4.3-deps sources are falling out of date. And I doubt > a bundle of 2.4.4-deps is going to be updated either. Note that pcre is not part of the deps tarball. For 2.2 I'd stick to the bundled pcre, but that's not a strong opinion. Note that when updating there's a chance of hitting incompatibilities with modules that also use PCRE like mod_security. Don't know how windows handles the use of two versions of a DLL in the same process. For 2.4 I think starting with latest pcre is fine, later major updates may depend on compatibility again. expat: currently still bundled directly or inside deps as apr-util builtin. No strong opinion here whether to use that one or the latest. I personally would stick to expat for 2.4 and not switch to libxml2. > For a binary package here at the ASF, when it comes to a third party > dependency, I would suggest we ignore the out of date bundled source, > and always package what the other OSS project has most recently > released, as long as the release remained binary forward compatible > to our prior packages. Bundled is only pcre (2.2) and expat (2.2, 2.4). As said for those I don't have a strong opinion. For the unbundled ones, the choice of the "right" version might depend on linker behaviour when different versions get mixed by httpd and 3rd-party modules. For a first binary build of 2.4 I would agree to choose the latest unbundled ones. > This impacts Windows and Netware along with any other binaries people > wanted to build (aix, solaris or whatever). In most of those cases > I'd expect the 'httpd' package would be devoid of the dependencies > and just rely on the most commonly accepted library bundle. I think > it is that way in most of the deb/rpm/apt packaging repositories. For Linux type platforms and more recent versions of the Unix platforms some of the deps exist in acceptable versions as part of the standard OS distribution. Because of 3rd-party module compatibility it might then be best to build against these versions. Regards, Rainer
