PHP 5.4.0 : lang/php54

[Doug Barton]

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