Date: Wed, 30 May 2012 21:32: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: <4FC675B3.9020204@acsalaska.net> In-Reply-To: <4FC501F9.8080304@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> 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. 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". >> 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. Fact is that right now, again, people that have their applications in shape have zero problems upgrading. I can easily state that people that don't want to upgrade can put a +IGNOREME in their respective ports or simply not run upgrades, but the fact of the matter is that the solution that satisfies all isn't that easy. 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. Secondly, it also installs only a fraction of it's bundled modules in the main port. This complicates the logic should you decide to use a single PKGPREFIX for for the different extensions as the distinfo, WRKSRC and possibly dependencies has to be set properly. Some packages have moved from pecl- to the main distribution in the past, which makes things even more complicated. Some lessons may be learned from Perl here, though I'm not sure if they have actually moved compiled modules from CPAN into the main source. 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? -- Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC675B3.9020204>