From owner-freebsd-ports@FreeBSD.ORG Tue May 29 11:00:10 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B57581065670; Tue, 29 May 2012 11:00:09 +0000 (UTC) (envelope-from rflynn@acsalaska.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id B08918FC08; Tue, 29 May 2012 11:00:09 +0000 (UTC) Received: from [127.0.0.1] (squeeze.lan.rachie.is-a-geek.net [192.168.2.30]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 487897E851; Tue, 29 May 2012 03:00:07 -0800 (AKDT) Message-ID: <4FC4AC34.70902@acsalaska.net> Date: Tue, 29 May 2012 13:00:04 +0200 From: Mel Flynn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Doug Barton References: <4FBA618A.1050707@freebsd.org> <20120521155736.GA79323@DataIX.net> <4FBA6FEB.1000706@quip.cz> <4FC45D40.4060200@FreeBSD.org> In-Reply-To: <4FC45D40.4060200@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Scheidell , Miroslav Lachman <000.fbsd@quip.cz>, freebsd-ports@freebsd.org Subject: Re: PHP 5.4.0 : lang/php54 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 11:00:10 -0000 On 29-5-2012 7:23, Doug Barton wrote: > On 5/21/2012 9:40 AM, Miroslav Lachman wrote: >> I think that the best will be to not have any default "php5" port and >> just use php52, php53, php54, php5X, php60... as we have apache20, >> apache22, apache24, or mysql50-server, mysql51-server, mysql55-server. >> >> There is no default apache2 or mysql5-server, so there is no confusion >> what is / what will be installed. >> >> Then it can be choosed in make.conf what version will be used as >> default, similar to WITH_MYSQL_VER=51 or APACHE_PORT=www/apache22 Doesn't make a difference as there is DEFAULT_MYSQL_VER and DEFAULT_APACHE_VERSION. > I have been advocating for this for years. IMO we shouldn't have *any* > unversioned ports for things that have multiple simultaneous versions > supported. I've actually done this for the things I support (most > notably bind*) for a long time, and have never had a single user complaint. Not too hard for leaf ports. But with ports that are depended on, there is always a default, whether it's named that way or not. You're just changing the problem slightly: 1) There's always need for repo copies, followed in the case of php by maintainer changes. (user don't care, until this visibly starts to slow down the port's upgrades or a previous version is suddenly without maintainer) 2) All ports that depend on "the previous default version" are assumed to be working with "the new default version". Instead of an "omfg I don't wanna upgrade" problem, you have an "I installed php-foo but it don't work!" problem and an additional "how do I upgrade to the new version?" problem. 3) Nobody seems to care that this should be addressed: a) upstream for breaking API in minor releases b) upstream for not releasing php6 where many of these features and obsoletions belong. c) depending packages for using features that have been deprecated for years. 4) There's simply no way to not select a default version, unless you want people to be confronted with "this port requires php but it's not installed". Either you make a meta-port which allows the user to select the php version it wants, or you provide a default. In case of a meta-port, I'd like to see the patches that handle changing the selected version in the meta port. Concluding from the above, having a lang/php port has the advantage that people tracking the latest version have zero issues installing and upgrading. Having only versioned ports means that there is always need for origin changes across multiple ports when upgrading to a new minor version which as far as I can tell, no ports-mgmt tool can handle in one invocation of the command. Has anyone been working/thinking on unifying the way various lang/* ports and their modules are handled across versions? -- Mel