Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 66330 invoked from network); 14 Jul 2004 18:33:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 14 Jul 2004 18:33:26 -0000 Received: (qmail 98572 invoked by uid 500); 14 Jul 2004 18:33:22 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 98418 invoked by uid 500); 14 Jul 2004 18:33:20 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 98362 invoked by uid 99); 14 Jul 2004 18:33:19 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Errors-To: Message-Id: <6.1.2.0.2.20040714110903.10b7eec0@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 14 Jul 2004 13:06:33 -0500 To: Joe Orton From: "William A. Rowe, Jr." Subject: Re: 1.0.0 RC4 Cc: APR Dev List In-Reply-To: <20040714154336.GB25656@redhat.com> References: <013f01c4691e$b0c2fa80$7500a8c0@goliath> <01e701c469b4$fc63b880$5308a8c0@robinson.cam.ac.uk> <20040714152133.GA25796@redhat.com> <026f01c469b7$e835ad20$5308a8c0@robinson.cam.ac.uk> <20040714154336.GB25656@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N At 10:43 AM 7/14/2004, Joe Orton wrote: >On Wed, Jul 14, 2004 at 04:33:14PM +0100, Max Bowsher wrote: >> Joe Orton wrote: >> >> RC4 is still installing /bin/apr-config , so making it impossible >> to >> >> install apr 0 and apr 1 side-by-side. >> > >> > Known issue, will get fixed sometime after 1.0.0 once everything else >> > has been hooked up to use apr-1-config. >> >> Won't that be too late, because of API compat requirements? > >Which answer do you prefer? :) > >1. No, apr-config is not part of the API >2. Yes, tough I was surprised that you missed #3. It's broke - but you get both pieces. I'm really not teasing - show us the code to fix the complaint. I do find it incredibly amusing and ironic that the same crew fighting with "which libtool rev will work?", due to *that* moving target, would endorse either answer 1. or 2. But, I have no intentions of installing apr globally on any box, so it doesn't affect me at all. Every application based on apr that I'm interested in I've always built against a private apr install. (As I say, I'm a vpath build addict.) So... The first group this primarily hurts are devs attempting to build against either, installed side-by-side (still trusting apr-config? outch, you are broke on 1.0.1). Document that they must use apr-1-config, they are fine. Ohhh, also document that they need to rename apr-config out of the way before 1.0 installation, and then copy it back. They are devs, it's not that difficult, and it gets them ready to build against apr 1.0.1. The other group this also hurts are OS packagers, who can't ship apr 1.0.0 as designed. Presuming they want to roll in apache 1.3, 2.0, and svn sometime in the near future, they just need to rejigger the finished set of files. The final group, app users, really won't notice. First, by the time they are ready to adopt an apr 1.0 app, 1.0.1 will be out and this will be fixed, perhaps. Provided the first two groups don't goof on our account. So I'm +1 for -beta, -0 for release. I won't block it. But I certainly hope those, who get so ticked off at the example of libtool's bogosity, would wish less pain and more consistency for _our_ end users. Just not looking forward to the day when "Why do my modules fail to build with apxs (-2.0)" start to show up on users@httpd. Bill