You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/12/01 01:33:51 UTC
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote:
> On Wed, Nov 30, 2005 at 09:22:58PM +0000, Nick Kew wrote:
>
>>Can someone clarify: what happens *by default* if APR 1.0/1.1 is
>>found on a target machine? If it tries to build against that, I'd
>>support a -1. If it does something sensible - which could be emitting
>>an error message and refusing to build - I'd not worry.
>
> It refuses to configure, you need to go build apr/apu 1.2 somewhere and
> reconfig with the --with-apr(-util) options.
Ok, so explain to me why we wasted a MB or two distributing srclib/apr/
and srclib/apr-util/ when the result is;
[wrowe@s170 httpd-2.2]$ ./configure
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
Configuring Apache Portable Runtime library ...
checking for APR... yes
setting CC to "gcc"
setting CPP to "gcc -E"
setting CFLAGS to " -g -O2 -pthread"
setting CPPFLAGS to " -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE"
setting LDFLAGS to " "
Configuring Apache Portable Runtime Utility library...
checking for APR-util... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
configure: Configuring PCRE regular expression library
configuring package in srclib/pcre now
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for bcopy... yes
checking for memmove... yes
checking for strerror... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating pcre.h
config.status: creating pcre-config
config.status: creating config.h
config.status: executing default commands
srclib/pcre configured properly
setting AP_LIBS to "/local0/asf/httpd-2.2/srclib/pcre/libpcre.la"
setting INCLUDES to "-I$(top_builddir)/srclib/pcre"
Configuring Apache httpd ...
adding "-I." to INCLUDES
adding "-I$(top_srcdir)/os/$(OS_DIR)" to INCLUDES
adding "-I$(top_srcdir)/server/mpm/$(MPM_SUBDIR_NAME)" to INCLUDES
adding "-I$(top_srcdir)/modules/http" to INCLUDES
adding "-I$(top_srcdir)/modules/filters" to INCLUDES
adding "-I$(top_srcdir)/modules/proxy" to INCLUDES
adding "-I$(top_srcdir)/include" to INCLUDES
adding "-I$(top_srcdir)/modules/generators" to INCLUDES
adding "-I$(top_srcdir)/modules/mappers" to INCLUDES
adding "-I$(top_srcdir)/modules/database" to INCLUDES
adding "-I/usr/local/include/apr-1" to INCLUDES
Applying OS-specific hints for httpd ...
forcing SINGLE_LISTEN_UNSERIALIZED_ACCEPT to "1"
forcing AP_NONBLOCK_WHEN_MULTI_LISTEN to "1"
checking for rm... /bin/rm
checking for pkg-config... /usr/bin/pkg-config
checking for rsync... /usr/bin/rsync
checking for gawk... gawk
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for lynx... lynx
checking for egrep... grep -E
checking for AIX... no
checking for library containing strerror... none required
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking for APR version 1.2.0 or later... no
configure: error: APR version 1.2.0 or later is required
This appears to be the worst of both worlds. -1 for release of the proposed
tarball in this state. Drop the srclib's or make the srclib's work, it doesn't
that much matter to me. But the above is sillyness at it's worst.
Bill
Re: [vote] 2.2.0 tarballs
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> If some random user has APR 1.1 installed in /usr/local/apr, and builds
> httpd 2.2 with --prefix=/usr/local/httpd-2.2, it would be a Bad Thing
> (and certainly, very surprising behaviour) if that httpd install went
> ahead and silently upgraded that APR install.
AGREED! Never silent - in fact if there is a conflict, present the user
two command line options to choose between.
> (APR 1.x has never been shipped in a Subversion tarball)
<light bulb>
Seriously? No applications? That significantly weakens my initial
objection, although still, this should be fixed soonish.
Bill
Re: [vote] 2.2.0 tarballs
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Dec 01, 2005 at 11:11:26AM +0100, Andreas Lindström wrote:
> > Any users who run httpd are unlikely to have installed APR 1.[01] given
> > that APR 1.x has never been supported by an httpd release to date. It's
> > really only httpd/APR developers who are likely to get into this
> > situation. (APR 1.x has never been shipped in a Subversion tarball)
>
> As far as i know APR 1.0 (1.1 perhaps) is the only APR that is
> available as a standalone APR with FreeBSD systems
Hmmm, The following list of ports;
mod_webapp, flood, subversion, c_c++_reference-2.0.2_3, chora-2.0,
cvs2svn-1.2.0, esvn-0.6.8, kdesdk-3.4.0, kdevelop-3.2.0,
p5-Log-Accounting-SVK-0.03,, p5-SVN-Mirror-0.56, p5-SVN-Simple-0.27,
p5-SVN-Web-0.38, p5-VCP-Dest-svk-0.28_1, psvn-10727, rapidsvn-0.7.0,
subversion-1.1.3, subversion-perl-1.1.3, subversion-python-1.1.3,
svk-0.30, instant-workstation-1.0_8, kdewebdev-3.4.0,2,
p5-Kwiki-Archive-SVK-0.11, trac-0.8, kde-3.4.0
is the full list apr-1 in some form as a B-dep or an R-dep.
instant-workstation and kde are a bit worrying it has to be said.
Though I think the workaround is still acceptable.
> Just to lift the two issues i know of atm and make sure they are at
> least being documented, here they are. First off, configure does not
> like it when you give the httpd configure the source trees to use
> (without running any other configures first), and... as the configure
> clearly states that this should work, how many users do you think is
> gonna do the configure in both apr and apr-util first and then run the
> httpd configure? (Really?!) Not that many i think, and if this is
> really how its released, then there should be a clear statement
> somewhere in the install docs or in configure itself that "this is not
> working, do it this way instead".
That's what release notes are for :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [vote] 2.2.0 tarballs
Posted by Andreas Lindström <an...@gmail.com>.
> Any users who run httpd are unlikely to have installed APR 1.[01] given
> that APR 1.x has never been supported by an httpd release to date. It's
> really only httpd/APR developers who are likely to get into this
> situation. (APR 1.x has never been shipped in a Subversion tarball)
As far as i know APR 1.0 (1.1 perhaps) is the only APR that is
available as a standalone APR with FreeBSD systems, and if i remember
correctly that APR gets installed as a prereq for Subversion if you
use ports to build it. Yes, this is probably not a very big problem as
Subversion is most likely used only by developers or other
knowledgeable people... however, i do not know how many other ports
installations that are using this APR. (Worst case, some really common
port uses it and all of a sudden this is a really big problem.)
Just to lift the two issues i know of atm and make sure they are at
least being documented, here they are. First off, configure does not
like it when you give the httpd configure the source trees to use
(without running any other configures first), and... as the configure
clearly states that this should work, how many users do you think is
gonna do the configure in both apr and apr-util first and then run the
httpd configure? (Really?!) Not that many i think, and if this is
really how its released, then there should be a clear statement
somewhere in the install docs or in configure itself that "this is not
working, do it this way instead".
Secondly, there was a huge buzz over mod_authn_dbd not working or
being built... but i dont see any buzz over mod_authnz_ldap not
working with newer versions of OpenSSL and OpenLDAP and
mod_authnz_ldap is actually included in the build, this is an issue
that also is a few weeks old, but has this even been documented
somewhere? Actually, wrowe, is this still true? Havent heard anything
so im kinda assuming that its still broken. And as OpenLDAP is
commonly used for system wide authentication i can definitely see
people screaming when they try to get their new Apache 2.2.0 to auth
against it as well, using SSL that is. This seems like an issue that
should be documented (if its still an issue) or i can see users@
beeing flooded here too.
/ Andreas
Re: [vote] 2.2.0 tarballs
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Nov 30, 2005 at 07:10:37PM -0600, William Rowe wrote:
> Colm MacCarthaigh wrote:
> >If apr 1.0 or 1.1 happen to be installed, I don't see why it's not
> >reasonable to fail to configure. The administrator may intend to link
> >against the system version, they may not want httpd having its own
> >libapr. And they're the only people capable of making that decision and
> >hence resolving the conflict. They can decide to install over their
> >existing apr, or to install a new one just for httpd.
> >
> >I brought this exact issue up weeks ago, and it didn't go very far. I
> >was originally -1, for the very same reasons you are, but having thought
> >about it decided that yes, while the present system introduces some
> >inconvienence for a small fraction of users, it doesn't try to second
> >guess them either, and unbundling apr/apr-util would represent a huge
> >inconvienence to a large fraction of users.
>
> I read this a bit backwards of your interpretation;
>
> * admins who install 1.1 for some specific reason are responsible to
> ensure they deal with the new package correctly (e.g., we give them
> a message upon configure "Found old APR 1.1.0, installing APR 1.2.2
> for you" and let them decide what to do. 99% of the time, they must
> follow our advise and install 1.2.2 in the same prefix/ as httpd.)
>
> * the vast majority of users, who only have apr 1.0/1.1 due to svn or
> other intrapackage dependencies, get a free apr 1.2 without having
> to think about it. Make this whole headache a noop for them.
If some random user has APR 1.1 installed in /usr/local/apr, and builds
httpd 2.2 with --prefix=/usr/local/httpd-2.2, it would be a Bad Thing
(and certainly, very surprising behaviour) if that httpd install went
ahead and silently upgraded that APR install.
(what if the APR configure options were wrong/different? what if the
APR 1.1 build had been custom-patched? etc)
Therefore I maintain that the current behaviour having configure fail if
the system APR/apr-util is not of sufficient version is the right thing
to do. The user can always force the use of the bundled copies (to be
installed in the same $prefix as httpd) as had been said many times.
> And I for one don't want the headaches of the users@ trouble reports. I'd
> really prefer to see those who help out on users@ answering this objection,
> as opposed to the hackers who are detached from the user community pushing
> this out +1 over those user-supporters objections.
Any users who run httpd are unlikely to have installed APR 1.[01] given
that APR 1.x has never been supported by an httpd release to date. It's
really only httpd/APR developers who are likely to get into this
situation. (APR 1.x has never been shipped in a Subversion tarball)
joe
Re: [vote] 2.2.0 tarballs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Dec 01, 2005 at 01:25:38AM +0000, Colm MacCarthaigh wrote:
> There's no reason why this can't be fixed during 2.2, but with a months
> old issue, and no sign of a patch, should it hold up a GA?
No way. -- justin
Re: [vote] 2.2.0 tarballs
Posted by Oden Eriksson <oe...@mandriva.com>.
torsdagen den 1 december 2005 16.01 skrev Nick Kew:
> On Thursday 01 December 2005 14:47, Oden Eriksson wrote:
> > I added mysql support in apr-util-1.2.2 as per INSTALL.MySQL as a
> > conditional build switch in our rpm package, that was only possible after
> > doing a lot of hacks.
>
> Are those hacks anything we/I should know about and fix, or are they
> specific to your packaging?
Well if you want to fix it it would be great. basically what I had to do was
to install these in the apr installbuilddir (in our apr-1.2.2 binary rpm):
apr_common.m4
apr_hints.m4
apr_network.m4
apr_threads.m4
find_apr.m4
gen-build.py
(I'm not sure all those *.m4 files was required)
After that mimic buildconf by copying them to the apr-util-1.2.2/build/
directory, followed by libtoolize --copy --force; aclocal; autoconf --force;
python build/gen-build.py make. After that apr-util-1.2.2 recognized the added
apr_dbd_mysql.c source. Of course this was done at rpm build time for
apr-util-1.2.2.
Cheers.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
Re: [vote] 2.2.0 tarballs
Posted by Nick Kew <ni...@webthing.com>.
On Thursday 01 December 2005 14:47, Oden Eriksson wrote:
> I added mysql support in apr-util-1.2.2 as per INSTALL.MySQL as a
> conditional build switch in our rpm package, that was only possible after
> doing a lot of hacks.
Are those hacks anything we/I should know about and fix, or are they
specific to your packaging?
--
Nick Kew
Re: [vote] 2.2.0 tarballs
Posted by Oden Eriksson <oe...@mandriva.com>.
torsdagen den 1 december 2005 07.54 skrev Roy T. Fielding:
> On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote:
> > I'm 100% conviced next to nobody on this list has been developing
> > and testing
> > httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty
> > as anyone.
> >
> > So we've been compiling and improving the code, but the build/
> > install status
> > is -worse- than httpd-2.0, ergo this is not "the best version of
> > apache now
> > available" and is -not- ready for GA.
>
> I just built from scratch using the tarball and the same options
> that any typical user would set: i.e.,
>
> ./configure --prefix=/dist/test22 --enable-modules=all
>
> Zero problems.
>
> I don't understand what you are talking about -- developers don't
> run ./buildconf on the source package. Only we do that. Even after
> I do a
I added mysql support in apr-util-1.2.2 as per INSTALL.MySQL as a conditional
build switch in our rpm package, that was only possible after doing a lot of
hacks.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://li.nux.se
Re: [vote] 2.2.0 tarballs
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Thu, Dec 01, 2005 at 04:06:37AM -0600, William A. Rowe, Jr. wrote:
> Ok, but did you try installing into a tree that has, say, a fink port of
> svn based on apr 1.0 or 1.1? We are (mostly) talking about where httpd
> is finding stale APR versions related to non-httpd packages. (Non-httpd,
> because httpd never has shipped anything but alphas based on 1.0 or 1.1.)
But are there any of these that we know of? fink's apr is 0.9 ;
http://pdb.finkproject.org/pdb/package.php/apr
and its svn depends on that too. This has got to affect a vanishly small
user base of people who know what they're doing :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [vote] 2.2.0 tarballs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Dec 01, 2005 at 04:06:37AM -0600, William A. Rowe, Jr. wrote:
> Ok, but did you try installing into a tree that has, say, a fink port of
> svn based on apr 1.0 or 1.1? We are (mostly) talking about where httpd
Subversion has never officially supported anything other than APR 0.9.x -
i.e. what comes with httpd 2.0.x.
Now, Subversion actually will work with APR 1.0 and higher mainly because I
make it do so. I personally don't run much with APR 0.9.x any more, but
I'm probably the only semi-active full committer on Subversion who does so.
No one on the Subversion lists will discuss using SVN and APR 1.0+ until,
and at least, httpd 2.2 goes GA. Chicken and egg in its finest.
So, claiming that there may be Subversion clients based on APR 1.0 or 1.1
would be against everything that the Subversion team recommends. -- justin
Re: [vote] 2.2.0 tarballs
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
> On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote:
>
>> So we've been compiling and improving the code, but the build/ install
>> status
>> is -worse- than httpd-2.0, ergo this is not "the best version of
>> apache now
>> available" and is -not- ready for GA.
>
> I just built from scratch using the tarball and the same options
> that any typical user would set: i.e.,
>
> ./configure --prefix=/dist/test22 --enable-modules=all
>
> Zero problems.
Ok, but did you try installing into a tree that has, say, a fink port of
svn based on apr 1.0 or 1.1? We are (mostly) talking about where httpd
is finding stale APR versions related to non-httpd packages. (Non-httpd,
because httpd never has shipped anything but alphas based on 1.0 or 1.1.)
> I don't understand what you are talking about -- developers don't
> run ./buildconf on the source package. Only we do that.
Ack, as I suggested, let's kill it in the source distro.
> again I have zero problems. The included versions of apr and apr-util
> are used in all of my tests. I've never installed apr-1.x in the OS
> system libraries. Why would anyone outside this list do that?
That's my -main- worry, those that didn't intend/deliberately install apr
at all, but picked up 1.0/1.1 from another package such as subversion.
Bill
Re: [vote] 2.2.0 tarballs
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote:
>
> I'm 100% conviced next to nobody on this list has been developing
> and testing
> httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty
> as anyone.
>
> So we've been compiling and improving the code, but the build/
> install status
> is -worse- than httpd-2.0, ergo this is not "the best version of
> apache now
> available" and is -not- ready for GA.
I just built from scratch using the tarball and the same options
that any typical user would set: i.e.,
./configure --prefix=/dist/test22 --enable-modules=all
Zero problems.
I don't understand what you are talking about -- developers don't
run ./buildconf on the source package. Only we do that. Even after
I do a
make extraclean
./buildconf
./configure --prefix=/dist/test22 --enable-modules=most
again I have zero problems. The included versions of apr and apr-util
are used in all of my tests. I've never installed apr-1.x in the OS
system libraries. Why would anyone outside this list do that?
> Those hyper to release, why not make it usable by Joe anybody
> instead of only
> httpd-dev hacker who's used to 'fudging the build'?
Whatever problem you are encountering, please fix it on trunk.
I see no evidence that it will cause people outside the APR core
development group any grief for httpd-2.2, and even then a workaround
can be described on the website.
....Roy
Re: [vote] 2.2.0 tarballs
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Colm MacCarthaigh wrote:
>
> There's no reason why this can't be fixed during 2.2, but with a months
> old issue, and no sign of a patch, should it hold up a GA?
I'm 100% conviced next to nobody on this list has been developing and testing
httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty as anyone.
So we've been compiling and improving the code, but the build/install status
is -worse- than httpd-2.0, ergo this is not "the best version of apache now
available" and is -not- ready for GA.
Those hyper to release, why not make it usable by Joe anybody instead of only
httpd-dev hacker who's used to 'fudging the build'?
Bill
Re: [vote] 2.2.0 tarballs
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Nov 30, 2005 at 07:10:37PM -0600, William A. Rowe, Jr. wrote:
> * admins who install 1.1 for some specific reason are responsible to
> ensure they deal with the new package correctly (e.g., we give them
> a message upon configure "Found old APR 1.1.0, installing APR 1.2.2
> for you" and let them decide what to do. 99% of the time, they must
> follow our advise and install 1.2.2 in the same prefix/ as httpd.)
>
> * the vast majority of users, who only have apr 1.0/1.1 due to svn or
> other intrapackage dependencies, get a free apr 1.2 without having
> to think about it. Make this whole headache a noop for them.
>
> And I for one don't want the headaches of the users@ trouble reports. I'd
> really prefer to see those who help out on users@ answering this objection,
> as opposed to the hackers who are detached from the user community pushing
> this out +1 over those user-supporters objections.
User trouble reports can be easily mitigated by including the
instructions;
If you are installing on a system with apr/apr-util 1.0 or 1.1
installed, you must provide apr 1.2 manually. You can decide to
upgrade your existing apr/apr-util installation(s) to 1.2, or
may use the bundled versions like so;
cd srclib/apr ; ./configure
cd srclib/apr-util ; ./configure --with-apr=../apr
./configure --with-apr=srclib/apr --with-apr-util=srclib/apr-util
in the release notes.
There's no reason why this can't be fixed during 2.2, but with a months
old issue, and no sign of a patch, should it hold up a GA?
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [vote] 2.2.0 tarballs
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Colm MacCarthaigh wrote:
> If apr 1.0 or 1.1 happen to be installed, I don't see why it's not
> reasonable to fail to configure. The administrator may intend to link
> against the system version, they may not want httpd having its own
> libapr. And they're the only people capable of making that decision and
> hence resolving the conflict. They can decide to install over their
> existing apr, or to install a new one just for httpd.
>
> I brought this exact issue up weeks ago, and it didn't go very far. I
> was originally -1, for the very same reasons you are, but having thought
> about it decided that yes, while the present system introduces some
> inconvienence for a small fraction of users, it doesn't try to second
> guess them either, and unbundling apr/apr-util would represent a huge
> inconvienence to a large fraction of users.
I read this a bit backwards of your interpretation;
* admins who install 1.1 for some specific reason are responsible to
ensure they deal with the new package correctly (e.g., we give them
a message upon configure "Found old APR 1.1.0, installing APR 1.2.2
for you" and let them decide what to do. 99% of the time, they must
follow our advise and install 1.2.2 in the same prefix/ as httpd.)
* the vast majority of users, who only have apr 1.0/1.1 due to svn or
other intrapackage dependencies, get a free apr 1.2 without having
to think about it. Make this whole headache a noop for them.
And I for one don't want the headaches of the users@ trouble reports. I'd
really prefer to see those who help out on users@ answering this objection,
as opposed to the hackers who are detached from the user community pushing
this out +1 over those user-supporters objections.
Bill
Re: [vote] 2.2.0 tarballs
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Wed, Nov 30, 2005 at 06:33:51PM -0600, William A. Rowe, Jr. wrote:
> Ok, so explain to me why we wasted a MB or two distributing srclib/apr/
> and srclib/apr-util/ when the result is;
That's not the result when you don't have apr/apu 1.x [x:<2] installed.
apr and apr-util 1.2 are bundled for reasons of pragmatic convienence,
recognising that the vast majority of people don't have these already.
If apr 1.0 or 1.1 happen to be installed, I don't see why it's not
reasonable to fail to configure. The administrator may intend to link
against the system version, they may not want httpd having its own
libapr. And they're the only people capable of making that decision and
hence resolving the conflict. They can decide to install over their
existing apr, or to install a new one just for httpd.
I brought this exact issue up weeks ago, and it didn't go very far. I
was originally -1, for the very same reasons you are, but having thought
about it decided that yes, while the present system introduces some
inconvienence for a small fraction of users, it doesn't try to second
guess them either, and unbundling apr/apr-util would represent a huge
inconvienence to a large fraction of users.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net