Summary: | php-ext-source-r2.eclass - The following REQUIRED_USE flag constraints are unsatisfied: any-of ( php_targets_php5-3 php_targets_php5-4 php_targets_php5-5 ) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sven E. <dark> |
Component: | Eclasses | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sven E.
2014-09-28 01:58:36 UTC
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? |