Even when PHP_TARGETS="php5-5", the package refuses to emerge with this message: The following REQUIRED_USE flag constraints are unsatisfied: any-of ( php_targets_php5-5 php_targets_php5-3 php_targets_php5-4 ) More details are at http://forums.gentoo.org/viewtopic-p-7375130.html Note that I can emerge dev-php/pecl-apcu-4.0.1 For your convenience, $ diff /usr/portage/dev-php/pecl-apcu/pecl-apcu-4.0.1.ebuild /usr/portage/dev-php/pecl-apcu/pecl-apcu-4.0.1-r1.ebuild 3c3 < # $Header: /var/cvsroot/gentoo-x86/dev-php/pecl-apcu/pecl-apcu-4.0.1.ebuild,v 1.1 2013/04/30 10:08:33 olemarkus Exp $ --- > # $Header: /var/cvsroot/gentoo-x86/dev-php/pecl-apcu/pecl-apcu-4.0.1-r1.ebuild,v 1.3 2013/08/13 21:55:55 ago Exp $ 22c22 < KEYWORDS="~amd64 ~x86" --- > KEYWORDS="amd64 x86" 45c45 < enable_extension_enable "apcu-mmap" "mmap" 0 --- > use mmap || my_conf+=" --disable-apcu-mmap" Regards, Sergio
Did you keyword the package (~arch)? Remember that pecl packages for php 5.5 still need to be keyworded.
I have the same behaviour with dev-php/xdebug-2.2.3: $ grep PHP_TARGETS /etc/make.conf PHP_TARGETS="php5-5" $ emerge -av xdebug ... !!! The ebuild selected to satisfy "xdebug" has unmet requirements. - dev-php/xdebug-2.2.3::gentoo USE="" PHP_TARGETS="-php5-3 -php5-4 -php5-5" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( php_targets_php5-5 php_targets_php5-3 php_targets_php5-4 )
*** Bug 482100 has been marked as a duplicate of this bug. ***
Ole Markus With, adding =dev-php/pecl-apcu-4.0.1-r1 to /etc/portage/package.accept_keywords resolved for me. Thank you for the "trick". But the portage management is unclear for me and the error message too. When emerging dev-php/pecl-apcu in a clean system (no dev-lang/php at all), I have: [ebuild N ] dev-php/pecl-apcu-4.0.1-r1 USE="lock_pthreadrw mmap -lock_pthreadmutex -lock_semaphore -lock_spinlock" PHP_TARGETS="php5-4 -php5-3 (-php5-5)" So, now I can understand. But in the development system, the --pretend --ask phase is skipped: # emerge -ap dev-php/pecl-apcu These are the packages that would be merged, in order: Calculating dependencies h !!! Problem resolving dependencies for dev-php/pecl-apcu ... done! !!! The ebuild selected to satisfy "dev-php/pecl-apcu" has unmet requirements. - dev-php/pecl-apcu-4.0.1-r1::gentoo USE="lock_pthreadrw mmap -lock_pthreadmutex -lock_semaphore -lock_spinlock" PHP_TARGETS="-php5-3 -php5-4 -php5-5" The following REQUIRED_USE flag constraints are unsatisfied: any-of ( php_targets_php5-5 php_targets_php5-3 php_targets_php5-4 ) The above constraints are a subset of the following complete expression: exactly-one-of ( lock_pthreadmutex lock_pthreadrw lock_spinlock lock_semaphore ) any-of ( php_targets_php5-5 php_targets_php5-3 php_targets_php5-4 ) Here the difference between 5-5 and the previous versions is not clear. Is there a little messages' jam or am I wrong? Regards, Sergio
(Edit: when I say «in the development system» I mean «where dev-lang/php-5.5.1 is already installed»)
(In addition to D.Raisin from comment #2) > I have the same behaviour with dev-php/xdebug-2.2.3: > ... Ah, thanks, Ole + Sergio echo "dev-php/xdebug" >> /etc/portage/accept_keywords fixed it for me. (Although I don't understand why this is needed. It's the first time I stumbled over this and I'm not particularly new to Portage.)
Sorry, I meant echo "dev-php/xdebug" >> /etc/portage/package.accept_keywords
Including the packages in /etc/portage/package.accept_keywords worked. Why is it necessary? The pecl packages in trying to emerge aren't in testing themselves: # cat /usr/portage/dev-php/pecl-apcu/pecl-apcu-4.0.1-r1.ebuild | grep KEYWORDS KEYWORDS="amd64 x86" Is there any other way/place that is putting these packages in testing?
(In reply to Rodrigo Severo from comment #8) > Including the packages in /etc/portage/package.accept_keywords worked. > > Why is it necessary? The pecl packages in trying to emerge aren't in testing > themselves: > > # cat /usr/portage/dev-php/pecl-apcu/pecl-apcu-4.0.1-r1.ebuild | grep > KEYWORDS > KEYWORDS="amd64 x86" > > Is there any other way/place that is putting these packages in testing? Yep. It is a bit funky. But we are working on fixing this.
This should now be fixed.
Fixed for me with last minute sync (with dev-lang/php-5.5.2).