From owner-freebsd-ports@FreeBSD.ORG Wed May 30 19:48:49 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 767241065673; Wed, 30 May 2012 19:48:49 +0000 (UTC) (envelope-from scheidell@freebsd.org) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [204.89.241.253]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC5F8FC0C; Wed, 30 May 2012 19:48:48 +0000 (UTC) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [10.70.1.253]) by mx1.secnap.com.ionspam.net (Postfix) with ESMTP id A0104621C08; Wed, 30 May 2012 15:48:48 -0400 (EDT) X-Virus-Scanned: SpammerTrap(r) VPS-1500 2.18 at mx1.secnap.com.ionspam.net Received: from USBCTDC001.secnap.com (usbctdc001.secnap.com [10.70.1.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.secnap.com.ionspam.net (Postfix) with ESMTPS id 8C094621C0E; Wed, 30 May 2012 15:48:47 -0400 (EDT) Received: from usbctlt011.secnap.com (10.70.2.19) by USBCTDC001.secnap.com (10.70.1.1) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 30 May 2012 15:48:47 -0400 Message-ID: <4FC6799F.8030602@freebsd.org> Date: Wed, 30 May 2012 15:48:47 -0400 From: Michael Scheidell Organization: SECNAP Network Security Corp User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; 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> <4FC501F9.8080304@FreeBSD.org> <4FC675B3.9020204@acsalaska.net> In-Reply-To: <4FC675B3.9020204@acsalaska.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , 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: Wed, 30 May 2012 19:48:49 -0000 On 5/30/12 3:32 PM, Mel Flynn wrote: > Right. The issue I'm talking about is that fixing the problem of staying > with a version, introduces a problem for people that have their software > up-to-date and don't use deprecated features. Instead of simply > upgrading they now have to jump through hoops of changing origins on > multiple ports and their depending ports. Each time a new perl version > is introduced or the default changes there are failure reports and > compared to php, perl is easy as the modules have a single prefix (p5-) > vs the versioned prefix now used by the php ports. Ditto on perl. UPDATING is wrong on steps. you can't upgrade perl, you need to delete it and everything it depends on and start from scratch. Remembering years of going through this, and as the maintainer of p5-Mail-SpamAssassin, all of a sudden, new OP's are installing SA with a copy of perl I never tested. From a CIO perspective, I have to track down, and spend many, many, many hours tracking down dependencies and fixing them. practical instance: In the middle of moving all of our servers from apache//php52 (since we moved them from php5 5.2.7, became php52), we weren't done. Got most of them to php5 (5.3.4 ish). Now, we need to move them to php5 (5.4), and, as a ports committer, I see all the ports that needed 'emergency' updates/patches/fixes because all of a sudden, a specific p5- port would not compile, or would not work. From a security standpoint, php5 (5.4) is not ready, and will not be deployed in our network. it was ~not~ regression tested against all the ports that it depends on, it does ~not~ have Suhosin patch. I know that regression testing will fail in our environment. SO, give us a way to keep php5 default as php5.3.4.... in make.conf, in environment, and when we add a new port, have it compile, package, install the php5 (5.3) version. My desire, from a CIO/CTO management perspective? Upwards compatibility. //// I have php5 (5.3.4) installed, I sorta want to keep it. Installing a php5 (5.4) p5- module automatically breaks things. What I am looking at now: I need to take a test box that has php5 (5.3.4) which works just fine, thank you, and try to rename them all to php53. I need to edit INDEX-7, do the same. Then I need to replicate my build environment (tinderbox, pre-build binary packages), and then do a portsnap, and upgrade EVERYTHING THAT TOUCHES php5 (to 5.3) then I have to disable a couple of modules, and try to reinstall them. and, bingo: someone change a library version number, and php won't run. All I am saying, from my perspective, is php5 should not have been set to php 5.4. We should have created (repocopy) a php54 branch, and let people test it before breaking them. Issac Asimov 1st rule of robotics 'Thou Shalt Not Kill'. Corollary in Software: MAKE IT UPWARD COMPATIBLE. -- Michael Scheidell, CTO >*| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell