Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 15 Jul 2004 11:00:34 -0700
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Noah Misch <noah@cs.caltech.edu>
cc: APR Dev List <dev@apr.apache.org>, jorton@redhat.com
Subject: Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0
 RC4 (apr-config -> apr-1-config)
Message-ID: <7766CD9323077204D4182A85@st-augustin.ics.uci.edu>
In-Reply-To: <20040715160716.GB1507@orchestra.cs.caltech.edu>
References: <013f01c4691e$b0c2fa80$7500a8c0@goliath>
 <01e701c469b4$fc63b880$5308a8c0@robinson.cam.ac.uk>
 <20040714152133.GA25796@redhat.com>
 <05ad01c469e8$eb104e20$5308a8c0@robinson.cam.ac.uk>
 <99CA65382203D77E24187888@[10.0.1.57]>
 <00f401c46a4f$726be210$5308a8c0@robinson.cam.ac.uk>
 <20040715100213.GB29967@redhat.com>
 <20040715123433.GA32693@orchestra.cs.caltech.edu>
 <B41E4FD5C0E535AEF4EE455D@[10.0.1.58]>
 <20040715160716.GB1507@orchestra.cs.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Thursday, July 15, 2004 9:07 AM -0700 Noah Misch <noah@cs.caltech.edu> 
wrote:

> If APR_FIND_APR accepts version constraints, should it not interpret them
> to at least the maximum granularity at which APR allows API changes?  I
> think this is not difficult:

I disagree.  When you have multiple parallel installs of the same major 
version all sorts of things can go wonky.

In your scenario, imagine: /usr having apr-1.1.5 installed and then 
/opt/apache having apr-1.2.5 installed.  That's going to be a nasty 
conflict when the user tries to run it depending upon the characteristics 
of the run-time linker (not to mention compiler search order).  You might 
override the one in /usr/lib with the one in /opt/apache or you might not.. 


I'd strongly prefer we not open the door to a slew of errors.  The 
granularity should be at the major version and no finer.  -- justin