Return-Path: 
 <dev-return-7724-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 34503 invoked by uid 500); 14 Aug 2002 20:32:44 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 34490 invoked from network); 14 Aug 2002 20:32:43 -0000
Date: Wed, 14 Aug 2002 21:27:11 +0100
From: Thom May <thom@planetarytramp.net>
To: dev@apr.apache.org
Cc: Justin Erenkrantz <jerenkrantz@apache.org>
Subject: Re: cvs commit: apr/test Makefile.in
Message-ID: <20020814202711.GA1932@eustasy>
Mail-Followup-To: dev@apr.apache.org,
	Justin Erenkrantz <jerenkrantz@apache.org>
References: <20020814171515.57745.qmail@icarus.apache.org>
 <20020814104633.D14316@lyra.org> <20020814180050.GO6479@apache.org>
 <20020814184109.GA822@eustasy> <20020814191105.GA10466@apache.org>
 <20020814125439.A14817@lyra.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020814125439.A14817@lyra.org>
User-Agent: Mutt/1.4i
X-Operating-System: Linux/2.4.19-ac4 (i686)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

* Greg Stein (gstein@lyra.org) wrote :
> On Wed, Aug 14, 2002 at 12:11:05PM -0700, Justin Erenkrantz wrote:
> >...
> > My concern is that this is attempting to enforce a versioning
> > scheme that isn't what everyone uses.  It's what you would use
> > if you use /usr and want to support multiple versions installed at
> > the same time.  Greg's commit locks everyone into this model, and the
> > more I think about it, I think that is harmful.
> 
> It is an improvement on our existing situation. In that sense, it is not
> harmful. The previous situation was hella more harmful.
> 
Definitely agreed.
> >...
> > If APR supported config.layout (easy enough to add), a layout
> > could have:
> 
> I would totally support adding such a notion, along with the
> ${major_version} example that you provided.
> 

This is really easy to do - the debian packages were doing exactly that for
a long time. I can resurrect that patch and apply it this evening if people
think it's a positive step?

> Note that I won't hold 0.9.0 for that, though. :-)  IMO, if the more
> flexible installation appears in 0.9.1 ... we're still doing fine by our
> users.
> 
> Do you suppose that the layout processing could be app-independent? For
> example, APR provides the functionality, and APR, httpd, and SVN could all
> use it?
> 
> [ I'm not trying to add work; if you do an APR-only solution, I'm still fine
>   with that... just another add'l feature ]
For sure. the layout stuff is defined as an autoconf macro, so svn would
just need to sinclude apr_layout.m4 or whatever, and then call the macro.
We would, I guess, update httpd so we just had one canonical
APR_LAYOUT implementation.
-Thom
> 

-- 
Thom May -> thom@planetarytramp.net

* moshez tries to understand why in god's name /usr is symlinked to / on the hurd
<vorlon-work> moshez: the same reason that /body/head is symlinked to /body/ass in some Hurd developers?
<vorlon-work> No, that's unkind.  /usr -> / makes more sense than the anatomy of said developers.