Justin Erenkrantz wrote:
I think it's the best way.
Maybe we could also provide two packages, httpd-with-apr and another one without apr
No, they should be separate, and having two different packages is just a recipie for trouble. (When you have to deal with a support problem, the guy who's having the problem will never know which package he downloaded.)
Remember you're dealing with two audiences here. There's an audience of people who compile from source, there's also the audience of people who use packaged libraries.
People in the second camp aren't going to suffer much hardship. Rpm, deb and other package managers know about dependencies, and newer tools (yum) will automatically track them down.
I'm in the first camp. Apache is an important enough piece of software that I'm not going to switch to some other web server because it's a little more work to compile. When compiling software, it's common to have to compile some libraries to compile the app, and this kind of split is even done with trivial software such as mp3-taggers.
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. 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.)
Also the stability of APR is going to matter. For a long time you had to run Subversion on APR out of CVS and I'd often update svn and then find that I had to update APR because they'd changed it so it depends on the latest APR.
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.
