Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Date: Wed, 11 Sep 2002 04:22:36 -0700
From: Justin Erenkrantz <jerenkrantz@apache.org>
To: test-dev@httpd.apache.org
Subject: Re: [PATCH] flood: install target
Message-ID: <20020911112235.GU4170@apache.org>
Mail-Followup-To: Justin Erenkrantz <jerenkrantz@apache.org>,
	test-dev@httpd.apache.org
References: <20020910190408.1affa5ef.jacek.prucia@7bulls.com>
 <20020910163958.GE4170@apache.org>
 <20020911140124.221e7eef.jacek.prucia@7bulls.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020911140124.221e7eef.jacek.prucia@7bulls.com>
User-Agent: Mutt/1.4i

On Wed, Sep 11, 2002 at 02:01:24PM +0200, Jacek Prucia wrote:
> Uhmm. And since I saw few +1's for splitting APR/APR-util and httpd
> releases, maybe we schould also get rid of those intree libs? I'll try
> to play around with external APR/APR-util and see if flood builds clean
> that way.

It should work just fine, if not, something broke.  =)

For releases, we want to include those day's snapshots of
APR/APR-util so that a person who downloads flood has everything
they need to build it - regardless if APR or APR-util change later
on in a way that breaks that release of flood.

As APR and APR-util have their own releases, the problem gets
slightly easier, but it's not a big deal as we should support both
methods.

> if you really don't like /usr/local (why? :), then we could use

/usr/local doesn't allow versioning of the install binaries.
Therefore, admins have to go to extreme lengths to support
parallel installs (as do developers to get their setups to
support parallel installs!).

To me, a better approach is to explicitly version the directories
and leave them there permanently, so that, flood 1.0 would be in
/pkg/flood-1.0, flood 1.1 in /pkg/flood-1.1, and flood 2.0 would be
in /pkg/flood-2.0.  This allows easy movement back and forth between
versions that isn't allowed in the /usr/local strategy.

(Realize that /pkg can be anything you like it to be.  Some places
use /opt or whatever.  I use /pkg for much the same reason fink uses
/sw - no one else uses that directory name.)

I've heard some people use symlink farms from explicitly versioned
directories into /usr/local to help with path issues, but I use a
tool called 'module' (tcl-based) to manage my path.

I've administered enough multi-user, multi-platform, multi-site
systems to learn that /usr/local is pure evil.

> /usr/local/flood  +1

/usr/local/flood is fine with me.  It fits with how httpd and APR
are setup by default.  -- justin