From owner-freebsd-ports@FreeBSD.ORG Tue May 29 17:06:03 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 2A6811065676; Tue, 29 May 2012 17:06:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BF321156F7F; Tue, 29 May 2012 17:06:02 +0000 (UTC) Message-ID: <4FC501F9.8080304@FreeBSD.org> Date: Tue, 29 May 2012 10:06:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mel Flynn References: <4FBA618A.1050707@freebsd.org> <20120521155736.GA79323@DataIX.net> <4FBA6FEB.1000706@quip.cz> <4FC45D40.4060200@FreeBSD.org> <4FC4AC34.70902@acsalaska.net> In-Reply-To: <4FC4AC34.70902@acsalaska.net> X-Enigmail-Version: 1.4.1 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 17:06:03 -0000 On 5/29/2012 4:00 AM, Mel Flynn wrote: > 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. The DEFAULT_ knobs give the system the ability to function in a multi-version environment. The WITH_ knobs give the user the ability to override the defaults to make their own systems internally consistent. Whenever I set up a package-building system I always specify a bunch of WITH_ values for certain key dependencies. I know that it works. >> 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: Not slight at all. I have dealt with many iterations of mass-updates to many systems caused by the silliness we're talking about here. If everyone affected by the lang/php debacle currently had been able to simply set WITH_PHP_VER= 53 prior to the default changing in order to stay at lang/php53, the introduction of lang/php54 would have been a no-op. It's a little bit of pain when you're talking about 1 or 2 systems. If you're talking about dozens, or hundreds, it's an issue that makes FreeBSD increasingly unusable on the enterprise level. > 1) There's always need for repo copies, There never was a need for repo copies. They have always been silly busy work that caused more harm than good. We're reaping the results of that in the cvs -> svn conversion now. (As an aside, I blame repo-copies as one of the reasons that we have this ridiculous "MUST PRESERVE THE HISTORY!!!" fetish ... as if not copying the history would have made it magically disappear from the old location.) > 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) Again, totally irrelevant to my point. If we had lang/php53 with maintainer A, and that person wanted to focus their attention on the new/shiny php54, no problem. New port is created by maintainer A, and maintainer B steps in to take over php53. Exactly as what is happening now. > 2) All ports that depend on "the previous default version" are assumed > to be working with "the new default version". Hopelessly naive. And demonstrably untrue in the case of PHP. > 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. The latter problem is soluble. Making the first problem go away is critical. > 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. We can't change the upstream behavior ... we can try, but ultimately we will never be 100% successful. We should design the ports system for reality, not what we wish were true. > c) depending packages for using features that have been deprecated > for years. To a certain extent I sympathize here, and there has to be a balance. (Witness the enthusiasm with which I swing the axe on old, unmaintained stuff.) However, if we are going to support multiple versions of stuff (which we clearly do), then that support should be robust, and meet the needs of our users. The status quo is neither. > 4) There's simply no way to not select a default version, You already described the mechanism, which works well. That part is a solved problem. > Concluding from the above, Your premises are flawed. Therefore your conclusions were as well. Doug -- This .signature sanitized for your protection