Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 01 Jun 2012 15:05:03 +0200
From:      Mel Flynn <rflynn@acsalaska.net>
To:        Doug Barton <dougb@FreeBSD.org>
Cc:        Michael Scheidell <scheidell@FreeBSD.org>, Miroslav Lachman <000.fbsd@quip.cz>, freebsd-ports@FreeBSD.org
Subject:   Re: PHP 5.4.0 : lang/php54
Message-ID:  <4FC8BDFF.40700@acsalaska.net>
In-Reply-To: <4FC6DED4.7030300@FreeBSD.org>
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> <4FC6DED4.7030300@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 31-5-2012 5:00, Doug Barton wrote:
> 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:

>> 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.

And users using "the latest php" in production don't have anything to
complain about as they have no problem. Maybe that's two people, maybe
it's the silent masses that will rain down on the mail servers once we
break their easy upgrade path.

> 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.

Yep, that's what I'm trying to get at. The ideal solution is to have a
system that can upgrade between minor versions and "micro versions"
without a difference to the end user. Major version upgrades are a
different ballgame entirely as upstream uses a much bigger axe, though
the differences between python2.x and 3.x are less big then I expected
initially.
But, if the ideal solution cannot be achieved, I'm not sure it's wise to
sacrifice a system that already does painless minor upgrades so that we
can have painless micro version upgrades.

>>>> 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.

Right and I'm describing the state of the code in the ports tree at the
moment. Even with ports that are fully versioned, they get marked for
specific versions based on user reports or maintainer insights. But if a
port works with "all versions in the ports tree at the moment" then it's
not tagged USE_PYTHON= <=32. It's marked as USE_PYTHON=yes, which means
'any'. The only way to fix that is to use an opt-in system for supported
versions, similar to MAKE_JOBS_SAFE. Right now, it's opt-out.

>>>> 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.

Well, if we agree that switching a branch should be no different to the
end user as upgrading within a branch then the additional issues I think
are:
- branches marked EOL upstream shall not live on forever (something to
think about really, since this will make people lazier)
- conflict resolution for modules that have been imported into or
ejected from the main source
- opt-in mechanism for versions rather than the current opt-out
- support for different maintainers per branch
- automatic activation of compiled modules in the case of php specifically
- a unified system for naming module ports from which the installed
interpreter version can be derived preferably without having multiple
origin incarnations of the same software
- Decision on whether to support multiple versions of the same
interpreter being installed and how to handle that if so (non-trivial)

>> 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."

Rss, fora, twitter and whatever medium upstreams support to stay current
with development.
-- 
Mel



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