I have an ebuild which uses php-ext-pecl-r2. It sets USE_PHP="php5-3 php5-4 php5-5". Even though php5-3 is set in PHP_TARGETS I am getting the following error message: The following REQUIRED_USE flag constraints are unsatisfied: any-of ( php_targets_php5-3 php_targets_php5-4 php_targets_php5-5 ) If I add php5-4 to PHP_TARGETS the error message goes away, but the PHP_TARGETS for the package does not include php5-3 when running emerge with -pv. Reproducible: Always Steps to Reproduce: n/a Actual Results: The value php5-3 in PHP_TARGETS seems to be ignored completely. Expected Results: Building the pecl extension for 5.3 The actual ebuild used to work just until recently and always properly built the extension for PHP 5.3 . The output of emerge is completely useless, as it asks to set php5-3 which is already in PHP_TARGETS.
The 5.3 target has been masked, and therefore, indeed, ignored. You will have to set PHP_TARGETS to php-5.4 or higher. And please do not add php5-3 to USE_PHP as php-5.3 will be removed sometime in the near future.
(In reply to Ole Markus With from comment #1) > The 5.3 target has been masked, and therefore, indeed, ignored. > > You will have to set PHP_TARGETS to php-5.4 or higher. And please do not add > php5-3 to USE_PHP as php-5.3 will be removed sometime in the near future. There's a minor thing though: as I noted in a couple bugs and a couple forum posts, php-ext-source-r2.eclass (as of rev 33) still has this line [[ -z "${USE_PHP}" ]] && USE_PHP="php5-3" ...an idea: just as is the case for python targets, move that to profiles ?
(In reply to Ole Markus With from comment #1) > The 5.3 target has been masked, and therefore, indeed, ignored. > > You will have to set PHP_TARGETS to php-5.4 or higher. And please do not add > php5-3 to USE_PHP as php-5.3 will be removed sometime in the near future. Unfortunately some apps (squirrelmail in my case) have a dep on 5.3. So, going for 5.4 is not really an option. removing php5-3 from USE_PHP won't help at all, will it?
BTW: Even if 5.3 was masked, the error message is misleading and faulty. If 5.3 was masked, then the error message should not list 5.3 as a viable option. Furthermore a non cryptic error message would tell the user a correct list of options and that the user selected a masked option. (So two messages, one for selecting a masked target, one listing options without the selected target, would be certainly okay and acceptable). A message that lists options which indeed are not available certainly is not. Sidenote: A similiar bug exists for ruby and ruby targets.
(In reply to Sven E. from comment #4) > BTW: Even if 5.3 was masked, the error message is misleading and faulty. > > If 5.3 was masked, then the error message should not list 5.3 as a viable > option. Furthermore a non cryptic error message would tell the user a > correct list of options and that the user selected a masked option. (So two > messages, one for selecting a masked target, one listing options without the > selected target, would be certainly okay and acceptable). A message that > lists options which indeed are not available certainly is not. > > Sidenote: A similiar bug exists for ruby and ruby targets. Yep. The error message for USE constraints in general is rather obscure. As for squirrelmail, I would say try the test version that allows for 5.5. Had you been on any other distro you would have had to upgrade a long time ago ...
(In reply to Ole Markus With from comment #5) > (In reply to Sven E. from comment #4) > > BTW: Even if 5.3 was masked, the error message is misleading and faulty. > > > > If 5.3 was masked, then the error message should not list 5.3 as a viable > > option. Furthermore a non cryptic error message would tell the user a > > correct list of options and that the user selected a masked option. (So two > > messages, one for selecting a masked target, one listing options without the > > selected target, would be certainly okay and acceptable). A message that > > lists options which indeed are not available certainly is not. > > > > Sidenote: A similiar bug exists for ruby and ruby targets. > > Yep. The error message for USE constraints in general is rather obscure. > > As for squirrelmail, I would say try the test version that allows for 5.5. > Had you been on any other distro you would have had to upgrade a long time > ago ... I try to avoid pres/betas/RCs and so on. It's a pitty squirrelmail seems somewhat frozen. I am thinking about moving away from squirrel but HORDE is a nightmare in many respects ;-). Other distros ... brings up the thought: "Eat crap, millions of flys can't be wrong" *SCNR* :-).
PHP 5.3 is in the process of being removed. Please follow bug 524216.
It does not matter if PHP 5.3 is deprecated. Invalid error messages and improper error handling are not acceptable, be it the pecl eclass or emerge's generalized error reporting logic. Or in other words: Just because the bug seems to vanish once PHP 5.3 is finally removed does not imply that's an acceptable error resolution procedure.
(In reply to Sven E. from comment #8) > It does not matter if PHP 5.3 is deprecated. > > Invalid error messages and improper error handling are not acceptable, be it > the pecl eclass or emerge's generalized error reporting logic. > > Or in other words: Just because the bug seems to vanish once PHP 5.3 is > finally removed does not imply that's an acceptable error resolution > procedure. If you don't like the error messages, then that is a portage bug. The PHP team does not control this. We only masked the flag in preparation to remove PHP 5.3. I cannot mask PHP 5.3 itself as it would block whole installs of packages instead of just features. Bugs are filed to change this and are listed in the tracker.
(In reply to Brian Evans from comment #9) > (In reply to Sven E. from comment #8) > > It does not matter if PHP 5.3 is deprecated. > > > > Invalid error messages and improper error handling are not acceptable, be it > > the pecl eclass or emerge's generalized error reporting logic. > > > > Or in other words: Just because the bug seems to vanish once PHP 5.3 is > > finally removed does not imply that's an acceptable error resolution > > procedure. > > If you don't like the error messages, then that is a portage bug. > The PHP team does not control this. We only masked the flag in preparation > to remove PHP 5.3. > > I cannot mask PHP 5.3 itself as it would block whole installs of packages > instead of just features. Bugs are filed to change this and are listed in > the tracker. Shouldn't the bug then be renamed and moved to the proper assignee? And who (if not the dev team/wranglers) should do that?
