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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
