Paul A. Houle said: > The one thing I'd worry about is maintainance. Suppose there's a > security flaw in APR... Well, Apache is in the front of your mind, but > APR isn't, so it might be easy to overlook the advisory.
A sysadmin would be looking out for more than just httpd advisories - openssl, php, perl - all of these others need to be monitored by a sysadmin. Thus the market for OS distros where this monitoring is done by the vendor for a fee. APR would just join that list (and already has). > Upgrading APR > might be a bit more confusing because the system might spend some time in > a state where APR is upgraded and Apache isn't -- what effects will that > have? (Probably none, but "probably" isn't a good answer for a > production server that 30,000 people depend on.) httpd depends on a minimum version of APR, but you can quite easily upgrade APR and not have to upgrade httpd. Forward compatibility is required of any APR release until a new major version is released. APR is no different to any other library httpd depends on (openssl, etc). > If APR is going to be reasonably stable in the future, then I feel OK > thinking of it as a system library. If, on the other hand, it's really > joined-at-the-hip to Apache and lots of app developers are building things > that need the CVS version of APR, it had better not be. APR has been stable for a long time now, and I know of no major projects that depend on a subversion version of APR. Regards, Graham --
