httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: [vote] 2.2.0 tarballs
Date Thu, 01 Dec 2005 08:35:21 GMT
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)


View raw message