From owner-freebsd-ports@FreeBSD.ORG Thu Aug 12 00:43:50 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC5AA16A4CE for ; Thu, 12 Aug 2004 00:43:50 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8878743D1F for ; Thu, 12 Aug 2004 00:43:50 +0000 (GMT) (envelope-from DougB@freebsd.org) Received: from lap (c-24-130-110-32.we.client2.attbi.com[24.130.110.32]) by comcast.net (sccrmhc12) with SMTP id <2004081200434901200pfrdqe>; Thu, 12 Aug 2004 00:43:49 +0000 Date: Wed, 11 Aug 2004 17:43:48 -0700 (PDT) From: Doug Barton To: freebsd-ports@freebsd.org Message-ID: <20040811172245.I54010@ync.qbhto.arg> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Projects with multiple versions in our ports tree X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 00:43:50 -0000 The bash thing today highlights a problem that's been buggin' me for a while now. We host a lot of third party projects that grow, fork, and diverge into various forms as time goes on. The autoconf/automake ports are probably the penultimate example of this, but I'm facing the same issue with the various versions of the BIND ports. The way that we've traditionally handled this is to have one canonical "foo" port, with various "fooNN" versions as needed. The negative part of this is that when the older version of "foo" becomes obsolete and one of the newer versions becomes the canonical one, we've had to do a lot of swapping around, repo-copying, etc. in order to handle the situation. At best this is sub optimal, and at worse it causes pointless delays and confusion. It also causes pointless upgrades for users who already have "fooNN" installed when "fooNN" becomes just plain "foo." I'd like to propose a different solution. In situations where there are likely to continue to be a large number of "fooNN" versions, "foo-devel" versions, etc, I'd like to suggest that we actually encourage the use of "fooNN" ports, and then have "some mechanism" that points "foo" ports at the right version of "fooNN." One mechanism that could work (perhaps with minor adjustments) is the master/slave port idea. If the "foo" port is simply a slave to the proper "fooNN" port, then that makes it very easy to adjust the "link" when needed. I'm not sure if this model would solve all the problems I outlined, but it would be a good start I think. I'm sure that some of our ports geniuses could come up with better potential solutions. What do y'all think? Doug -- This .signature sanitized for your protection