PHP 5.4.0 : lang/php54

Doug Barton dougb at
Thu May 31 03:00:47 UTC 2012

On 05/30/2012 12:32, Mel Flynn wrote:
> On 29-5-2012 19:06, Doug Barton wrote:
>> On 5/29/2012 4:00 AM, Mel Flynn wrote:
>>> On 29-5-2012 7:23, Doug Barton wrote:
>>> 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.
> 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.

I understand what you're saying, but in practice users generally don't
need to upgrade the version of a dependency that they are using, at
least not until it goes EOL. In the case of PHP, users actively oppose
being forced to upgrade, as indicated pretty clearly by the demand for
php52 and php53 ports.

That said, I agree that we need a more robust way to say "Upgrade my
perl/php/whatever from version N to version N+M." I am happy to put
effort into that if we can get general agreement on what a versioned
infrastructure should look like. Right now we have at least 4 different
models that I can think of off the top of my head, none of which
robustly address our users' needs.

>>> 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.
> No, it's the assumption made by the ports system as is - both now and if
> you'd version all PHP ports.

And as you say below, "Stating it doesn't make it true." We already know
that it absolutely is *not* true for PHP, it's only sometimes true for
Perl, often isn't true for Python ... etc. I know we'd really like it if
this were true, but it quite simply isn't; and isn't going to be any
time in the foreseeable future. We need to code for what is, not what we
wish it would be.

> Maintainers get a heads up of a new
> version, but in practice not all have the time to fully test if their
> application is ready for it and the ones not being able to test in time
> are simply "assumed to be working".

Right, which is one of the benefits of a versioned system. For example,
if the maintainer of a PHP port could say, "My port works with versions
up to 53" then when 54 comes out, users who want that leaf port will get
the dependency on php53 until the maintainer can certify that it works
with 54, and bump the dependency in the Makefile. As it is now, if that
leaf port doesn't work with 54 the user is screwed.

>>> 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.
> Stating it, doesn't make it true.

Not sure which you are referring to here. The "upgrade to the new
version" problem is a SMOP. If we can agree on what a framework should
look like, we can write tools to do it. But the haphazard way in which
it's handled now does not lend itself to a programmatic solution.

> First of all, php is an oddball in the interpreted languages, since it's
> loadable module directory is not based on release versions but API
> compatibility. While in theory that's a good thing, it also means that
> if the module API does not change, that the dependency tracking of the
> port system fails, as the module will be in exactly the same spot for
> version X as version Y. Possible solution here is to force depending
> packages to use a pkg_info-based dependency.

I understand the mechanics of the PHP problem pretty well, and the Perl
problems intimately. I'm also relatively familiar with the related
Python problem. My proposed solution addresses all of those, along with
the same problem in leaf ports like BIND and Postfix.

> Finally, if you have a vast number of machines to worry about, know how
> the php port works and see trouble ahead because of incompatibilities
> introduced, then why on earth are you not using a local version of the
> port and merge at your own leisure?

The key bit in your paragraph above is, "see troubles ahead." Right now
we have a ports system that needs a non-trivial amount of hand-holding
for people who want to keep large production environments running
smoothly. Not to mention causing a lot of pain for users with smaller
installations who are just trying to keep their ports up to date. What I
would like to see us do is remove some of that pain, and make things
easier to manage across the board.



    This .signature sanitized for your protection

More information about the freebsd-ports mailing list