Slotable php-5.3.3-r3 just hit the tree, after upgrade there wasn't any einfo/ewarn in postinst() about new config path layout like: php-5.3 now uses /etc/php/<API Name>-php5.3/ instead of /etc/php/<API Name>-php5/. Most users will just do upgrade, then dispatch-conf, they will see there only upgrade for init script and most likly they will not migrate thier config to new directory. I think you guys should cover it, provide any info about new path layout to not let users run into problems, rightnow it is really careless upgrade which I sure will be a problem. Reproducible: Always Steps to Reproduce: 1. sync tree, upgrade php. Actual Results: There is no info about how and why you need migrate your configs.
The package was put in ~arch under the assumption that users using ~arch are able to either deal with this issue themselves or ask for help. The package itself works out of the box and the application it builds is already available as a stable package for at least amd64 and x86. The issue here is not the quality of the ebuild itself, but rather about the lack of documentation around how these minor version slotted ebuilds work. Note that a lot of this is already documented in [1] (including the specific case that Piotr complained about regarding slots and config locations), but [1] should be mentioned in pkg_postinst and it should also mention how PHP_TARGETS work. [1] also deserves a general cleanup before the minor version slotted ebuilds becomes stable. Thanks for reporting this issue. [1] http://www.gentoo.org/proj/en/php/php-guide.xml
It's a misconception and bad style to assume any broken stuff can be dumped into ~arch without proper preparation and without any documentation. This dump is causing problems as it blocks lots of packages, which should have been tested for and fixed before it was put in the tree. The link you give doesn't explain anything of the steps taken by the php team here, and it's a pity. During my 8 years with gentoo these things happens now and then, and it's only human to make mistakes but it's to show characted to admit to them and fixing it rather then making excuses. I always run ~arch and there are seldom any problems and if there is I'm prepared to deal with them, but it doesn't mean we who do are some kind of dustbin you can just trow anything at. A small announcement on f.g.o with simple instructions on how to deal with this update, or at least an einfo about it in the ebuild, is in place and won't take many minutes to wrap up.
Well I forgot to include a thanks for working with and maintaining php, and want to stress that I think the php team most of the time make an excelent job. My opinion is just that this roll out could have been done better ;-) and many packages are still blocked...
(In reply to comment #3) > > and many packages are still blocked... > If you cannot live without pecl packages that are currently blocked I would downgrade to stable php-5.3 instead. We do not have any schedule for when every extension will have a php-ext-*-r2.eclass compatible ebuild.
That's not the point, I have already solved my problems. The point is that instead of getting recognition for your (great) work, you will upset ppl by a) putting this in the tree with many extension packages in block b) by not providing any docs how to deal with it and it doesn't matter if your assumtions are correct or not. It's just a pity.
[ebuild N ] dev-php5/suhosin-0.9.32.1-r1 117 kB [blocks B ] =dev-lang/php-5.3.3-r3 ("=dev-lang/php-5.3.3-r3" is blocking dev-php5/suhosin-0.9.32.1-r1) [ebuild R ] dev-php5/xcache-1.3.0 0 kB [blocks B ] =dev-lang/php-5.3.3-r3 ("=dev-lang/php-5.3.3-r3" is blocking dev-php5/xcache-1.3.0) Seems like nothing already works with the newest php ebuild. The only thing i can do now is to mask it, revert changes and go back to -r1. I dont really understand why isn't it blocked yet? :| If user uses ~, that does not mean he need to have knowledge to work with eclasses and ebuilds. I personally don't see other way to deal with this issue. Yes, You can say everyone can mask it - but if this is the only solution, it SHOULD be masked globally! What is more, to be honest, i cannot agree it works out of the box. There is no information about made changes and none from available extensions work with this.
(In reply to comment #6) > [ebuild N ] dev-php5/suhosin-0.9.32.1-r1 117 kB > [blocks B ] =dev-lang/php-5.3.3-r3 ("=dev-lang/php-5.3.3-r3" is blocking > dev-php5/suhosin-0.9.32.1-r1) > [ebuild R ] dev-php5/xcache-1.3.0 0 kB > [blocks B ] =dev-lang/php-5.3.3-r3 ("=dev-lang/php-5.3.3-r3" is blocking > dev-php5/xcache-1.3.0) > > > Seems like nothing already works with the newest php ebuild. The only thing i > can do now is to mask it, revert changes and go back to -r1. > > I dont really understand why isn't it blocked yet? :| If user uses ~, that does > not mean he need to have knowledge to work with eclasses and ebuilds. I > personally don't see other way to deal with this issue. Yes, You can say > everyone can mask it - but if this is the only solution, it SHOULD be masked > globally! > > What is more, to be honest, i cannot agree it works out of the box. There is no > information about made changes and none from available extensions work with > this. > It's definetely true. I have the same problem with this php ebuild. You have to distinguish between stable, testing and experimental. Stable is arch. Testing is ~arch. Experimental is ~arch with unmasked packages. Saying experimental I mean software with some untested/unpublished since now features, bugfixes, etc. Don't mess this. In my honest opinion of course.
Documentation is out and links added to ebuilds. Next time we do something like this, we will provide more documentation upfront. I promise.
