PHP 5.4.0 : lang/php54

[Mel Flynn]

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.

> 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:
1) There's always need for repo copies, 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)
2) All ports that depend on "the previous default version" are assumed
to be working with "the new default version". 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.
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.
   c) depending packages for using features that have been deprecated
      for years.
4) There's simply no way to not select a default version, unless you
want people to be confronted with "this port requires php but it's not
installed". Either you make a meta-port which allows the user to select
the php version it wants, or you provide a default. In case of a
meta-port, I'd like to see the patches that handle changing the selected
version in the meta port.

Concluding from the above, having a lang/php port has the advantage that
people tracking the latest version have zero issues installing and
upgrading. Having only versioned ports means that there is always need
for origin changes across multiple ports when upgrading to a new minor
version which as far as I can tell, no ports-mgmt tool can handle in one
invocation of the command.

Has anyone been working/thinking on unifying the way various lang/*
ports and their modules are handled across versions?
-- 
Mel