From owner-freebsd-ports@FreeBSD.ORG Thu May 31 03:00:47 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 5AEE0106566C; Thu, 31 May 2012 03:00:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 24D2C15638B; Thu, 31 May 2012 03:00:37 +0000 (UTC) Message-ID: <4FC6DED4.7030300@FreeBSD.org> Date: Wed, 30 May 2012 20:00:36 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120506 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mel Flynn References: <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> In-Reply-To: <4FC675B3.9020204@acsalaska.net> X-Enigmail-Version: 1.5pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Scheidell , Miroslav Lachman <000.fbsd@quip.cz>, freebsd-ports@freebsd.org Subject: Re: PHP 5.4.0 : lang/php54 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 03:00:47 -0000 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. Doug -- This .signature sanitized for your protection