Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 May 2012 15:48:47 -0400
From:      Michael Scheidell <scheidell@freebsd.org>
To:        Mel Flynn <rflynn@acsalaska.net>
Cc:        Doug Barton <dougb@freebsd.org>, Miroslav Lachman <000.fbsd@quip.cz>, freebsd-ports@freebsd.org
Subject:   Re: PHP 5.4.0 : lang/php54
Message-ID:  <4FC6799F.8030602@freebsd.org>
In-Reply-To: <4FC675B3.9020204@acsalaska.net>
References:  <CA%2BdUSyp2ztuZdCocnpNCgf-h%2BJO4zMMFEMi_xrm8nbwQ2W9How@mail.gmail.com>	<CADLo83_-UOWSc_suztjLBk0xYu_wu1TSN29Nwarn=nsFRv_TFQ@mail.gmail.com>	<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>

next in thread | previous in thread | raw e-mail | index | archive | help


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.

<text>
<soapbox>
 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.
</soapbox>
</text>
-- 
Michael Scheidell, CTO
 >*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC6799F.8030602>