Re: PHP 5.4.0 : lang/php54
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
Re: PHP 5.4.0 : lang/php54
On 05/30/2012 12:48, Michael Scheidell wrote: > Ditto on perl. UPDATING is wrong on steps. you can't upgrade perl, you > need to delete it and everything it depends on and start from scratch. For portmaster, you can do this which catches the majority of problems. portmaster -o lang/perlNEWVER lang/perlOLDVER portmaster p5 What I usually do then is troll the lib/perl5 directories to see if anything is left, and force an upgrade on it. Not elegant, but it works. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
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
Re: PHP 5.4.0 : lang/php54
On 05/29/2012 12:08, Matthew D. Fuller wrote: > On Tue, May 29, 2012 at 11:48:00AM -0700 I heard the voice of > Doug Barton, and lo! it spake thus: >> The whole concept of category/portname where there are multiple >> versions of portname is flawed. The DEFAULT_PORTNAME_VER mechanism >> works just fine, especially for dependencies. > > The disadvantage though is that we need to grow and use b.p.m > infrastructure then for every port we start handling multiple versions > of. No, only for those ports that are depended on, where multiple versions can be used to fulfill a dependency. The full-blown infrastructure would only be needed in this case. For leaf ports (ala bind*) it's not needed at all, and for other depended ports (ala libtorrent-rasterbar*) where only one version is suitable (or desirable) for the leaf it's not necessary. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 5/30/12 3:32 PM, Mel Flynn 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. Ditto on perl. UPDATING is wrong on steps. you can't upgrade perl, you need to delete it and everything it depends on and start from scratch. Remembering years of going through this, and as the maintainer of p5-Mail-SpamAssassin, all of a sudden, new OP's are installing SA with a copy of perl I never tested. From a CIO perspective, I have to track down, and spend many, many, many hours tracking down dependencies and fixing them. practical instance: In the middle of moving all of our servers from apache//php52 (since we moved them from php5 5.2.7, became php52), we weren't done. Got most of them to php5 (5.3.4 ish). Now, we need to move them to php5 (5.4), and, as a ports committer, I see all the ports that needed 'emergency' updates/patches/fixes because all of a sudden, a specific p5- port would not compile, or would not work. From a security standpoint, php5 (5.4) is not ready, and will not be deployed in our network. it was ~not~ regression tested against all the ports that it depends on, it does ~not~ have Suhosin patch. I know that regression testing will fail in our environment. SO, give us a way to keep php5 default as php5.3.4 in make.conf, in environment, and when we add a new port, have it compile, package, install the php5 (5.3) version. My desire, from a CIO/CTO management perspective? Upwards compatibility. I have php5 (5.3.4) installed, I sorta want to keep it. Installing a php5 (5.4) p5- module automatically breaks things. What I am looking at now: I need to take a test box that has php5 (5.3.4) which works just fine, thank you, and try to rename them all to php53. I need to edit INDEX-7, do the same. Then I need to replicate my build environment (tinderbox, pre-build binary packages), and then do a portsnap, and upgrade EVERYTHING THAT TOUCHES php5 (to 5.3) then I have to disable a couple of modules, and try to reinstall them. and, bingo: someone change a library version number, and php won't run. All I am saying, from my perspective, is php5 should not have been set to php 5.4. We should have created (repocopy) a php54 branch, and let people test it before breaking them. Issac Asimov 1st rule of robotics 'Thou Shalt Not Kill'. Corollary in Software: MAKE IT UPWARD COMPATIBLE. -- Michael Scheidell, CTO >*| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On Tue, May 29, 2012 at 11:48:00AM -0700 I heard the voice of Doug Barton, and lo! it spake thus: > > With respect to those involved, the lang/python port is a special > kind of problem. I agree. IME, it causes more confusion than it solves. I don't ever bother having lang/python on any systems; I just install whichever version (the latest, as a rule) I want, and if I ever find 'python' itself installed I mutter under my breath and pkg_delete it as fast as my fingers can fly. > The whole concept of category/portname where there are multiple > versions of portname is flawed. The DEFAULT_PORTNAME_VER mechanism > works just fine, especially for dependencies. The disadvantage though is that we need to grow and use b.p.m infrastructure then for every port we start handling multiple versions of. We need the vars, the switches for defaults, we need a special USE_* var (and maybe with multiple magic values for modular stuff like PHP), ports need to all use that instead of just RUN_DEPENDS'ing on a binary, blah blah blah. That doesn't scale for crap. (not germane to this particular case of course, since that's already all there for PHP, but it makes for an ugly general solution :| ) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 5/29/2012 11:25 AM, Olli Hauer wrote: > On 2012-05-29 19:06, Doug Barton wrote: >> On 5/29/2012 4:00 AM, Mel Flynn wrote: >>> 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. >> >> The DEFAULT_ knobs give the system the ability to function in a >> multi-version environment. The WITH_ knobs give the user the ability to >> override the defaults to make their own systems internally consistent. >> Whenever I set up a package-building system I always specify a bunch of >> WITH_ values for certain key dependencies. I know that it works. >> 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: >> >> 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. > > > Perhaps it is a good idea to move php5 -> php54 and create a meta > control port lang/php5 (like the lang/python port). With respect to those involved, the lang/python port is a special kind of problem. In cleaning up some systems where different people had done updates at different times in the past I ran into problems where lang/python was installed along with one or more (conflicting) lang/pythonNN ports. Unraveling that caused a non-zero amount of pain. The whole concept of category/portname where there are multiple versions of portname is flawed. The DEFAULT_PORTNAME_VER mechanism works just fine, especially for dependencies. One thing that would make this easier for users is to flag the default version somewhere, probably the pkg-descr, so that it's easier for users faced with multiple fooNN ports to figure out which one to install. > This will give the maintainer the ability to bump the php version and > users the ability to define PHP53 as default in make.conf. > As advantage users don't have to user other tools to fix dependencies > and paths in /var/db/pkg/* You don't need an unversioned port to do that. Witness the various versions of berkeley db. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 2012-05-29 19:06, Doug Barton wrote: > On 5/29/2012 4:00 AM, Mel Flynn wrote: >> 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. > > The DEFAULT_ knobs give the system the ability to function in a > multi-version environment. The WITH_ knobs give the user the ability to > override the defaults to make their own systems internally consistent. > Whenever I set up a package-building system I always specify a bunch of > WITH_ values for certain key dependencies. I know that it works. > >>> 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: > > 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. Perhaps it is a good idea to move php5 -> php54 and create a meta control port lang/php5 (like the lang/python port). This will give the maintainer the ability to bump the php version and users the ability to define PHP53 as default in make.conf. As advantage users don't have to user other tools to fix dependencies and paths in /var/db/pkg/* [snip] >> 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. Learned the hard way this weekend, I had to downgrade a couple of machines since I have applications which are using the KOHANA framwork. Luckily it was only a define in tinderbox build.xxx delting all php and pear ports and do a full rebuild of nearly 2000 ports (different database versions and archs) [ snip ] ... -- Regards, olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 5/29/2012 4:00 AM, Mel Flynn wrote: > 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. The DEFAULT_ knobs give the system the ability to function in a multi-version environment. The WITH_ knobs give the user the ability to override the defaults to make their own systems internally consistent. Whenever I set up a package-building system I always specify a bunch of WITH_ values for certain key dependencies. I know that it works. >> 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: 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. It's a little bit of pain when you're talking about 1 or 2 systems. If you're talking about dozens, or hundreds, it's an issue that makes FreeBSD increasingly unusable on the enterprise level. > 1) There's always need for repo copies, There never was a need for repo copies. They have always been silly busy work that caused more harm than good. We're reaping the results of that in the cvs -> svn conversion now. (As an aside, I blame repo-copies as one of the reasons that we have this ridiculous "MUST PRESERVE THE HISTORY!!!" fetish ... as if not copying the history would have made it magically disappear from the old location.) > 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) Again, totally irrelevant to my point. If we had lang/php53 with maintainer A, and that person wanted to focus their attention on the new/shiny php54, no problem. New port is created by maintainer A, and maintainer B steps in to take over php53. Exactly as what is happening now. > 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. > 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. > 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. We can't change the upstream behavior ... we can try, but ultimately we will never be 100% successful. We should design the ports system for reality, not what we wish were true. >c) depending packages for using features that have been deprecated > for years. To a certain extent I sympathize here, and there has to be a balance. (Witness the enthusiasm with which I swing the axe on old, unmaintained stuff.) However, if we are going to support multiple versions of stuff (which we clearly do), then that support should be robust, and meet the needs of our users. The status quo is neither. > 4) There's simply no way to not select a default version, You already described the mechanism, which works well. That part is a solved problem. > Concluding from the above, Your premises are flawed. Therefore your conclusions were as well. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
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 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. OTOH, the user confusion, broken systems, and generally huge amount of hassle caused by moving the default version of an important port like php to one that isn't compatible with the previous default only has downsides. In the days when the total number of ports, and the number of versioned ports, were both much smaller, the idea of a "default" version made sense. Neither has been true for a decade or more. Maybe it's time to make the rules and write them in to the Porter's Handbook and/or Committers guide. I don't know who can make this decision. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
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 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. OTOH, the user confusion, broken systems, and generally huge amount of hassle caused by moving the default version of an important port like php to one that isn't compatible with the previous default only has downsides. In the days when the total number of ports, and the number of versioned ports, were both much smaller, the idea of a "default" version made sense. Neither has been true for a decade or more. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 21/05/2012 20:03, Etienne Robillard wrote: On 05/21/2012 02:51 PM, George Kontostanos wrote: On Mon, May 21, 2012 at 6:36 PM, Chris Rees wrote: On May 21, 2012 4:17 PM, "George Kontostanos" wrote: Dear all, I just wanted to understand why did php54 became the default php port. Considering that the majority of my clients want to stick with php53 with the susosin patch, I can't blame them, it is really very annoying that we have to schedule a down time window so that we migrate from php to php53. Because currently there is no other way to do it unless you delete all your php5 packages and recompile them again under php53. Sure, the web server will still work even if you delete all php5 packages as long as apache doesn't restart. But there are many applications who make certain php cli calls. Those will not work! So, my question to the maintainers is, was there a particular reason that made you take this decision? When would have been a better time? Chris As a rule of thumb, the best time to mark a port as being the default is when there is a demand for it. As a side note, given the fact that FreeBSD is and should be the number 1 choice for webservers we have to make sure that before we proceed to such a major change we have: 1) A documented upgrade path 2) A documented roll back path Currently, if we want to stay up to date, we have to either nuke php5 and reinstall php53 or nuke php5 and reinstall php54. This requires down time work and effort. I would never complain if there was a security issue that had to make me recompile the full php suite. But now, I have to explain to many customers why I need down time in order for them to continue using the php53 version. Cheers Or in pkgtools.conf, add something to disallow upgrading inconditionally php ports if they're sensitive to your business workflow. hope this helps, E http://gthcfoundation.org/ this does seem to be an unfortunate upgrade path as the options for my clients were: default upgrade -> move to a non suhosin, some major cms broken (albeit better) version 5.4 'stay' on 5.3, paradoxically requiring a deletion of existing php5/php5-extensions ports tree and a reinstall from php53 which had no history of previous extensions. deletion of sqllite at same time didn't help -- - Paul Macdonald IFDNRG Ltd Web and video hosting - t: 0131 5548070 m: 07970339546
Re: PHP 5.4.0 : lang/php54
On 05/21/2012 02:51 PM, George Kontostanos wrote: On Mon, May 21, 2012 at 6:36 PM, Chris Rees wrote: On May 21, 2012 4:17 PM, "George Kontostanos" wrote: Dear all, I just wanted to understand why did php54 became the default php port. Considering that the majority of my clients want to stick with php53 with the susosin patch, I can't blame them, it is really very annoying that we have to schedule a down time window so that we migrate from php to php53. Because currently there is no other way to do it unless you delete all your php5 packages and recompile them again under php53. Sure, the web server will still work even if you delete all php5 packages as long as apache doesn't restart. But there are many applications who make certain php cli calls. Those will not work! So, my question to the maintainers is, was there a particular reason that made you take this decision? When would have been a better time? Chris As a rule of thumb, the best time to mark a port as being the default is when there is a demand for it. As a side note, given the fact that FreeBSD is and should be the number 1 choice for webservers we have to make sure that before we proceed to such a major change we have: 1) A documented upgrade path 2) A documented roll back path Currently, if we want to stay up to date, we have to either nuke php5 and reinstall php53 or nuke php5 and reinstall php54. This requires down time work and effort. I would never complain if there was a security issue that had to make me recompile the full php suite. But now, I have to explain to many customers why I need down time in order for them to continue using the php53 version. Cheers Or in pkgtools.conf, add something to disallow upgrading inconditionally php ports if they're sensitive to your business workflow. hope this helps, E http://gthcfoundation.org/ -- Etienne Robillard Occupation: Software Developer Company:Green Tea Hackers Club Email: e...@gthcfoundation.org Website:gthcfoundation.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On Mon, 2012-05-21 at 18:40 +0200, 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. +1 I really appreciate Alex's work, and seeing these lines : php5-5.3.13 < needs updating (port has 5.4.3) php5-bz2-5.3.13 < needs updating (port has 5.4.3) php5-ctype-5.3.13 < needs updating (port has 5.4.3) php5-curl-5.3.13< needs updating (port has 5.4.3) [...] in my cron-based portaudit/portversion output always means some extra work to keep a stable server running even after some simple freebsd-updated and portupgrade -arvbp... (-> first put php5 on HOLD in pkgtools.conf, then "dowgrade" from php5 to php53, etc... or even some work with portdowngrade). So this solution without a default php5 port would be perfect here, IMHO of course :-) Kind regards & have a nice week, Olivier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On Mon, May 21, 2012 at 6:36 PM, Chris Rees wrote: > > On May 21, 2012 4:17 PM, "George Kontostanos" > wrote: >> >> Dear all, >> >> I just wanted to understand why did php54 became the default php port. >> >> Considering that the majority of my clients want to stick with php53 >> with the susosin patch, I can't blame them, it is really very annoying >> that we have to schedule a down time window so that we migrate from >> php to php53. >> >> Because currently there is no other way to do it unless you delete all >> your php5 packages and recompile them again under php53. Sure, the web >> server will still work even if you delete all php5 packages as long as >> apache doesn't restart. But there are many applications who make >> certain php cli calls. Those will not work! >> >> So, my question to the maintainers is, was there a particular reason >> that made you take this decision? >> >> > > When would have been a better time? > > Chris As a rule of thumb, the best time to mark a port as being the default is when there is a demand for it. As a side note, given the fact that FreeBSD is and should be the number 1 choice for webservers we have to make sure that before we proceed to such a major change we have: 1) A documented upgrade path 2) A documented roll back path Currently, if we want to stay up to date, we have to either nuke php5 and reinstall php53 or nuke php5 and reinstall php54. This requires down time work and effort. I would never complain if there was a security issue that had to make me recompile the full php suite. But now, I have to explain to many customers why I need down time in order for them to continue using the php53 version. Cheers -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On Mon, May 21, 2012 at 06:40:11PM +0200, Miroslav Lachman wrote: > Jason Hellenthal wrote: > > > > > > On Mon, May 21, 2012 at 11:38:50AM -0400, Michael Scheidell wrote: > >> > >> > >> On 5/21/12 11:36 AM, Chris Rees wrote: > >>> When would have been a better time? > >>> > >> after it was regression tested? > >> after the security posture (susosin patch) wasn't downgraded? > > > > after a announcement in ports/UPDATING saying it will become the default > > no later than ...XX...XX...XX days "be prepared!" > > 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 > I agree. This does seem like a very sane option. -- - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Jason Hellenthal wrote: On Mon, May 21, 2012 at 11:38:50AM -0400, Michael Scheidell wrote: On 5/21/12 11:36 AM, Chris Rees wrote: When would have been a better time? after it was regression tested? after the security posture (susosin patch) wasn't downgraded? after a announcement in ports/UPDATING saying it will become the default no later than ...XX...XX...XX days "be prepared!" 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 Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
After a reasonable amount of time has passed so more applications properly support it ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On Mon, May 21, 2012 at 11:38:50AM -0400, Michael Scheidell wrote: > > > On 5/21/12 11:36 AM, Chris Rees wrote: > > When would have been a better time? > > > after it was regression tested? > after the security posture (susosin patch) wasn't downgraded? after a announcement in ports/UPDATING saying it will become the default no later than ...XX...XX...XX days "be prepared!" > > -- > Michael Scheidell, CTO > >*| * SECNAP Network Security Corporation > d: +1.561.948.2259 > w: http://people.freebsd.org/~scheidell > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 5/21/12 11:36 AM, Chris Rees wrote: When would have been a better time? after it was regression tested? after the security posture (susosin patch) wasn't downgraded? -- Michael Scheidell, CTO >*| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On May 21, 2012 4:17 PM, "George Kontostanos" wrote: > > Dear all, > > I just wanted to understand why did php54 became the default php port. > > Considering that the majority of my clients want to stick with php53 > with the susosin patch, I can't blame them, it is really very annoying > that we have to schedule a down time window so that we migrate from > php to php53. > > Because currently there is no other way to do it unless you delete all > your php5 packages and recompile them again under php53. Sure, the web > server will still work even if you delete all php5 packages as long as > apache doesn't restart. But there are many applications who make > certain php cli calls. Those will not work! > > So, my question to the maintainers is, was there a particular reason > that made you take this decision? > > When would have been a better time? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 5/21/12 11:17 AM, George Kontostanos wrote: Because currently there is no other way to do it unless you delete all your php5 packages and recompile them again under php53. I think there was a published 'hack' to let you rename everything php5->php53 in /var/db/pkg and /var/db/ports. This is actually something I will be doing soon, because there are enough incompatibilities with php54 (see the ports pr's with 'emergency' fixes and patches), that I am concerned about out own internal code. php54 seems to be a major api change from php53. -- Michael Scheidell, CTO >*| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 15 May 2012 11:17, Michael Scheidell wrote: > -1 > susosin patch is not a 'compatibility' issue. it is a security issue. > I would consider recommending a lang/php54 port, for people who absolutely > need it. include the 'WITH_SUHOSIN_PATCH' knob and mark it 'IGNORE' so that > anyone who expects the stsndard, default, upward compatible security will be > warned against installing this port. > > leave php5.3 the default lang/php5 for now. wait till suhosin patch is > released. use lang/php54 for anyone who absolutely must play with 5.4 > (I am still going through pains replacing apache 13 and php5.2 with nginx > and php53). don't think I want to /_by default_/ open up a security hole. +1 this is imho the best solution available -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 5/15/12 11:05 AM, Svyatoslav Lempert wrote: So I think we need release a new version without suhosin patch and check the compatibility of all ports that depend on it (before), and then when suhosin will appear (if there), then simply add it to the port. -1 susosin patch is not a 'compatibility' issue. it is a security issue. I would consider recommending a lang/php54 port, for people who absolutely need it. include the 'WITH_SUHOSIN_PATCH' knob and mark it 'IGNORE' so that anyone who expects the stsndard, default, upward compatible security will be warned against installing this port. leave php5.3 the default lang/php5 for now. wait till suhosin patch is released. use lang/php54 for anyone who absolutely must play with 5.4 (I am still going through pains replacing apache 13 and php5.2 with nginx and php53). don't think I want to /_by default_/ open up a security hole. -- Michael Scheidell, CTO >*| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
2012/5/15 Olivier Mueller : >> >> FreeBSD 8.3 is done, please commit update lang/php5 to PHP 5.4 to >> >> portstree. Thank you in advance. >> > >> > I'm just waiting for final release of suhosin (both patch and extension) >> > to commit the update. >> >> Do you know the release date of suhosin for this version? Stefan Esser >> did not make any changes in git repo >> https://github.com/stefanesser/suhosin more than a month and did not >> answer to email. Maybe should do without it? > > It seems there is still some activity, check for example the comments: > https://github.com/stefanesser/suhosin/issues/14 > > "Just as a reminder that PHP 5.4.x is not yet supported. > Current tree compiles against it, without disabling features. > However some problems with the dropped variable statistics and the > session module." > > > and https://github.com/stefanesser/suhosin/issues/5#issuecomment-5612025 : > > "Initial support" means that it now compiles against PHP 5.4 in a > correct way. However PHP 5.4 has a myriad of code changes and therefore > stuff might still be broken. > It is already known that there is a problem with sessions and gallery." > > > So it will probably take a while... (which is fine for me, I'll have to > switch to lang/php53 anyway then). > So I think we need release a new version without suhosin patch and check the compatibility of all ports that depend on it (before), and then when suhosin will appear (if there), then simply add it to the port. For me personally actual version 5.2 (for really old scripts that are used by our customers and I support this version in backports) and the new version 5.4 for new installations -- Svyatoslav ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Hi Svyatoslav, On Sat, 2012-05-12 at 03:12 +0900, Svyatoslav Lempert wrote: > 2012/4/19 Alex Dupre : > >> FreeBSD 8.3 is done, please commit update lang/php5 to PHP 5.4 to > >> portstree. Thank you in advance. > > > > I'm just waiting for final release of suhosin (both patch and extension) > > to commit the update. > > Do you know the release date of suhosin for this version? Stefan Esser > did not make any changes in git repo > https://github.com/stefanesser/suhosin more than a month and did not > answer to email. Maybe should do without it? It seems there is still some activity, check for example the comments: https://github.com/stefanesser/suhosin/issues/14 "Just as a reminder that PHP 5.4.x is not yet supported. Current tree compiles against it, without disabling features. However some problems with the dropped variable statistics and the session module." and https://github.com/stefanesser/suhosin/issues/5#issuecomment-5612025 : "Initial support" means that it now compiles against PHP 5.4 in a correct way. However PHP 5.4 has a myriad of code changes and therefore stuff might still be broken. It is already known that there is a problem with sessions and gallery." So it will probably take a while... (which is fine for me, I'll have to switch to lang/php53 anyway then). Regards, Olivier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 5/11/12 2:12 PM, Svyatoslav Lempert wrote: 2012/4/19 Alex Dupre: FreeBSD 8.3 is done, please commit update lang/php5 to PHP 5.4 to portstree. Thank you in advance. I'm just waiting for final release of suhosin (both patch and extension) to commit the update. Do you know the release date of suhosin for this version? Stefan Esser did not make any changes in git repo https://github.com/stefanesser/suhosin more than a month and did not answer to email. Maybe should do without it? I would almost say, fine, sure, but send it out at php54 and not php5. I would not recommend making the default something that comes out of the box, less secure than the old version. -- Michael Scheidell, CTO >*| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
2012/4/19 Alex Dupre : >> FreeBSD 8.3 is done, please commit update lang/php5 to PHP 5.4 to >> portstree. Thank you in advance. > > I'm just waiting for final release of suhosin (both patch and extension) > to commit the update. > Do you know the release date of suhosin for this version? Stefan Esser did not make any changes in git repo https://github.com/stefanesser/suhosin more than a month and did not answer to email. Maybe should do without it? -- Svyatoslav ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Svyatoslav Lempert ha scritto: > FreeBSD 8.3 is done, please commit update lang/php5 to PHP 5.4 to > portstree. Thank you in advance. I'm just waiting for final release of suhosin (both patch and extension) to commit the update. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Hello, Alex! FreeBSD 8.3 is done, please commit update lang/php5 to PHP 5.4 to portstree. Thank you in advance. I'm really waiting for this moment because I was going to install a large number of new servers with the new version of PHP (version 5.4 should be so you do not have a problem with a major update of the working of the system) and allready waited for several weeks. Who needs the old 5.3 - can roll back the version of the ports to today's date and solve the question with lang/php53 2012/3/12 Alex Dupre : > I've already created patches to update the current php5 port to 5.4. I'm > waiting for fixes to other main php-related ports and the end of ports > freeze to make them public and then commit them. > I'm tired to listen at every PHP release that we should not update > because everything broke (and on the other side people asking me when > the port will be update, because it has incredible new features). > Updating php port is a big task and will be done with the correct > timing. Functions removed in php5.4 have been deprecated 10 year ago, if > you still rely on them after more than 2 years PHP 5.3.0 has been > released, then probably you should stick to lang/php52 port, or find a > maintainer and a committer willing to create and maintain lang/php53. > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On 12.03.12 09:45, Alex Dupre wrote: Mr Dandy wrote: May be more correctly set PHP 5.4 by default to lang/php5, and repocopy current lang/php5 into lang/php53? Probably current maintainer of php (@ale) has the plan ;) released, then probably you should stick to lang/php52 port, or find a maintainer and a committer willing to create and maintain lang/php53. Just so everyone knows. I'm working on keeping PHP 5.3 and all it's slave ports. Other volunteers welcome of course. Florian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
> Anyway I think that the steps of launching a new port/port usage/port > deprecation is necessary for this exact reason. The other way would be to > freeze all the tree from time to time (i.e. several months) and ask projects > maintainers/developers to stick to each freeze. FreeBSD system do that, but > in userland it is imho not possible due to the big amount of ports available, > dependencies, conflicts, etc. > I think the best thing to actually do lang/php53 who need it. And to maintain it. Just need to make this port at one time with the update php5 to version 5.4 and is described in UPDATING -- Svyatoslav ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Le 12 mars 2012 à 15:00, Miroslav Lachman a écrit : > Jerry wrote: >> On Mon, 12 Mar 2012 13:19:40 +0100 >> Miroslav Lachman articulated: >> >>> I really understand that you don't have a time or will to maintain >>> more than 1 version of PHP - it is not an easy task. But what is the >>> difference between more versions of PHP in the ports tree and more >>> versions of Python, Perl, MySQL, Postgresql, Postfix... and many more >>> ports? There is always some reason why they are there. >>> Some of them (Perl 5.8 comes to my mind) are/were in the tree for a >>> long time after upstream EOL. >>> >>> Personally - I don't need older PHP versions for webaplications >>> written by my-self, but there are many hosted websites depending on >>> an older versions on our webhosting servers. Customers must wait for >>> update from their vedors etc. Even some mainstream Open Source CMS >>> and other applications lags behind PHP development. >> >> The primary reason that so many older/EOL'd versions of programs are >> still in existence is because by nature most individuals are just plain >> lazy. Face it, man only invented electricity because watching TV by >> candle light was not very convenient. >> >> Seriously though, all too many users have to be dragged into the future >> or else they will just rot in the past. If support for EOL'd crap was >> implemented immediately, support for the newer versions would be >> instituted lickety-split. > > It is not about EoL in the first place. PHP 5.3 is still maintained branch by > vendor. > And if we are talking about more than one branch... FreeBSD exists in 3 > parallel branches + HEAD. Plus this way of thinking does not let place for inertia of big projects. Especially collaborative projects where you can have thousand of developers btw. You cannot ask all projects/piece of code to be ready to upgrade to new version at the same time, and I'm not speaking of projects that involve many other technologies than PHP. Some projects simply cannot follow the vendor versioning rate just because of inertia, just to say. Maybe this could also be a way to go here at some point, I cannot tell. Anyway I think that the steps of launching a new port/port usage/port deprecation is necessary for this exact reason. The other way would be to freeze all the tree from time to time (i.e. several months) and ask projects maintainers/developers to stick to each freeze. FreeBSD system do that, but in userland it is imho not possible due to the big amount of ports available, dependencies, conflicts, etc. But as I said, this is only my point of view, we will conform to any change since we have not enough ressources to handle or maintain a port like PHP. For the moment, I can say that this is not a lazy task when you have tens of servers to maintain, and this is why I started to post in this thread... > > Miroslav Lachman > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Jerry wrote: On Mon, 12 Mar 2012 13:19:40 +0100 Miroslav Lachman articulated: I really understand that you don't have a time or will to maintain more than 1 version of PHP - it is not an easy task. But what is the difference between more versions of PHP in the ports tree and more versions of Python, Perl, MySQL, Postgresql, Postfix... and many more ports? There is always some reason why they are there. Some of them (Perl 5.8 comes to my mind) are/were in the tree for a long time after upstream EOL. Personally - I don't need older PHP versions for webaplications written by my-self, but there are many hosted websites depending on an older versions on our webhosting servers. Customers must wait for update from their vedors etc. Even some mainstream Open Source CMS and other applications lags behind PHP development. The primary reason that so many older/EOL'd versions of programs are still in existence is because by nature most individuals are just plain lazy. Face it, man only invented electricity because watching TV by candle light was not very convenient. Seriously though, all too many users have to be dragged into the future or else they will just rot in the past. If support for EOL'd crap was implemented immediately, support for the newer versions would be instituted lickety-split. It is not about EoL in the first place. PHP 5.3 is still maintained branch by vendor. And if we are talking about more than one branch... FreeBSD exists in 3 parallel branches + HEAD. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Le 12 mars 2012 à 09:45, Alex Dupre a écrit : > Mr Dandy wrote: >> May be more correctly set PHP 5.4 by default to lang/php5, and repocopy >> current lang/php5 into lang/php53? >> >> Probably current maintainer of php (@ale) has the plan ;) > > I've already created patches to update the current php5 port to 5.4. I'm > waiting for fixes to other main php-related ports and the end of ports > freeze to make them public and then commit them. > I'm tired to listen at every PHP release that we should not update > because everything broke (and on the other side people asking me when > the port will be update, because it has incredible new features). > Updating php port is a big task and will be done with the correct > timing. Functions removed in php5.4 have been deprecated 10 year ago, if > you still rely on them after more than 2 years PHP 5.3.0 has been > released, then probably you should stick to lang/php52 port, or find a > maintainer and a committer willing to create and maintain lang/php53. As a small ISP/hosting company I understand very well both sides, since we have boxes on which we will need to keep php52, and other boxes on which we want to use php54 as soon as it will be ready in ports. But as others said, I think that the issue should be addressed the same way as for i.e. python or perl, I mean one port per version lang/php52 lang/php53 lang/php54 etc. and by consequence no lang/php port Why ? because this would be safer for users (no accidental version upgrade), and easier to handle for admin. Imho I would even try to separate completely php version and allow install of several versions in parallel. Maybe this is harder to "insert" in ports tree - you know certainly better that I - but some other ports could then set dependencies over specific PHP version. The point that you have no time to maintain more than one version at a time is not a real problem btw, we all know the enormous/great work you're doing on this since years, and I would not complain if from time to time you say "I'm moving to new php version". Older versions will then enter in "looking for new maintainer port" list and stay in port tree until someone can take care of it, or until some security/age stuffs push it in removed port list... My 2 cts. David, a happy user ;) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On Mon, 12 Mar 2012 13:19:40 +0100 Miroslav Lachman articulated: > I really understand that you don't have a time or will to maintain > more than 1 version of PHP - it is not an easy task. But what is the > difference between more versions of PHP in the ports tree and more > versions of Python, Perl, MySQL, Postgresql, Postfix... and many more > ports? There is always some reason why they are there. > Some of them (Perl 5.8 comes to my mind) are/were in the tree for a > long time after upstream EOL. > > Personally - I don't need older PHP versions for webaplications > written by my-self, but there are many hosted websites depending on > an older versions on our webhosting servers. Customers must wait for > update from their vedors etc. Even some mainstream Open Source CMS > and other applications lags behind PHP development. The primary reason that so many older/EOL'd versions of programs are still in existence is because by nature most individuals are just plain lazy. Face it, man only invented electricity because watching TV by candle light was not very convenient. Seriously though, all too many users have to be dragged into the future or else they will just rot in the past. If support for EOL'd crap was implemented immediately, support for the newer versions would be instituted lickety-split. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Alex Dupre wrote: Mr Dandy wrote: May be more correctly set PHP 5.4 by default to lang/php5, and repocopy current lang/php5 into lang/php53? Probably current maintainer of php (@ale) has the plan ;) I've already created patches to update the current php5 port to 5.4. I'm waiting for fixes to other main php-related ports and the end of ports freeze to make them public and then commit them. I'm tired to listen at every PHP release that we should not update because everything broke (and on the other side people asking me when the port will be update, because it has incredible new features). Updating php port is a big task and will be done with the correct timing. Functions removed in php5.4 have been deprecated 10 year ago, if you still rely on them after more than 2 years PHP 5.3.0 has been released, then probably you should stick to lang/php52 port, or find a maintainer and a committer willing to create and maintain lang/php53. I really understand that you don't have a time or will to maintain more than 1 version of PHP - it is not an easy task. But what is the difference between more versions of PHP in the ports tree and more versions of Python, Perl, MySQL, Postgresql, Postfix... and many more ports? There is always some reason why they are there. Some of them (Perl 5.8 comes to my mind) are/were in the tree for a long time after upstream EOL. Personally - I don't need older PHP versions for webaplications written by my-self, but there are many hosted websites depending on an older versions on our webhosting servers. Customers must wait for update from their vedors etc. Even some mainstream Open Source CMS and other applications lags behind PHP development. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Mr Dandy wrote: > May be more correctly set PHP 5.4 by default to lang/php5, and repocopy > current lang/php5 into lang/php53? > > Probably current maintainer of php (@ale) has the plan ;) I've already created patches to update the current php5 port to 5.4. I'm waiting for fixes to other main php-related ports and the end of ports freeze to make them public and then commit them. I'm tired to listen at every PHP release that we should not update because everything broke (and on the other side people asking me when the port will be update, because it has incredible new features). Updating php port is a big task and will be done with the correct timing. Functions removed in php5.4 have been deprecated 10 year ago, if you still rely on them after more than 2 years PHP 5.3.0 has been released, then probably you should stick to lang/php52 port, or find a maintainer and a committer willing to create and maintain lang/php53. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
Mr Dandy wrote: On Sunday 11 March 2012 19:29:09 Svyatoslav Lempert wrote: Hello, please look http://www.freebsd.org/cgi/query-pr.cgi?pr=165933 May be more correctly set PHP 5.4 by default to lang/php5, and repocopy current lang/php5 into lang/php53? It is to early to make it a default PHP port. 5.4 is not backward compatible with 5.3 and it will be really bad for users to accidentaly upgrade to 5.4 instead of just update 5.3 install. +1 for make it lang/php54 for those who need it / want it to testing and development. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
2012/3/12 Mr Dandy : >> please look http://www.freebsd.org/cgi/query-pr.cgi?pr=165933 > > May be more correctly set PHP 5.4 by default to lang/php5, and repocopy > current lang/php5 into lang/php53? > No, I wrote about this a few weeks ago to ports@ - PHP 5.4 is not compatible with PHP 5.3, depricated funtions now removed. > Probably current maintainer of php (@ale) has the plan ;) > > PS: It will be nice to add an option for build PHP with DTRACE support: > Of course all this discussion, I posted "actually draft" -- Svyatoslav ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP 5.4.0 : lang/php54
On Sunday 11 March 2012 19:29:09 Svyatoslav Lempert wrote:
> Hello,
> please look http://www.freebsd.org/cgi/query-pr.cgi?pr=165933
May be more correctly set PHP 5.4 by default to lang/php5, and repocopy
current lang/php5 into lang/php53?
Probably current maintainer of php (@ale) has the plan ;)
PS: It will be nice to add an option for build PHP with DTRACE support:
--- php54.orig/Makefile 2012-03-11 19:52:35.235493071 +0400
+++ php54/Makefile 2012-03-11 19:48:13.0 +0400
@@ -46,6 +46,7 @@
MULTIBYTE "Enable zend multibyte support" off \
IPV6 "Enable ipv6 support" on \
MAILHEAD "Enable mail header patch" off \
+ DTRACE "Build with DTrace probes" off
CONFLICTS= php4-4* php5-pcre-* php5-spl-* php52-*
@@ -132,6 +133,10 @@
CONFIGURE_ARGS+=--disable-ipv6
.endif
+.if defined(WITH_DTRACE)
+CONFIGURE_ARGS+=--enable-dtrace
+.endif
+
post-patch:
@${TOUCH} ${WRKSRC}/ext/php_config.h
@${REINPLACE_CMD} "s|^\(extension_dir\)|; \1|" ${WRKSRC}/php.ini-*
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
