| Summary: | portageq calls are not allowed in the global scope | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Brian Harring (RETIRED) <ferringb> |
| Component: | New packages | Assignee: | Robin Johnson <robbat2> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | apache-bugs, dev-portage, php-bugs, qa, sebastian |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
mod_php required changes
mod_scgi required changes Fixed dev-php/jpgraph. Fixed dev-php/eaccelerator. |
||
|
Description
Brian Harring (RETIRED)
2005-09-27 21:35:52 UTC
Created attachment 69386 [details, diff]
mod_php required changes
robbat2, one for you....
Created attachment 69387 [details, diff]
mod_scgi required changes
apache crew, your patch.
Please leave the stern warning about never replicating that code anywhere else
in the tree in place please- it's not going to work 6 months down the line, so
people shouldn't use it in anyother packages (shouldn't anyways for QA reasons,
but that's seperate ;)
This need for has_version *should* actually be fixed with the new-style apache that just went stable due to the eclass handling all the depends in a correct way........ (we actually no longer support installing a single module for both versions of apache - you get apache-1 or apache-2 that the module is built against) Brian> can you take a peek at the depend.apache.eclass and see if this is broken? This is the what all the apache modules are supposed to be using. The old-style is deprecated and won't be supported much longer (3 months MAX) your APACHE1_DEPEND/APACHE2_DEPEND should be controlled by use conditionals... Portage should get it right since the ranged version is just a floor, but would avoid it till ranged versions are known to behave for all cases (my opinion). As long as nothing is setting metadata based on APACHE_VER for ebuilds that use that eclass, looks sane. Still need to fix the existing mod_php ebuilds though, which I'd suggest using my patch to tweak now (so I don't break it immediately), then eye migrating/deprecating :) Adding php herd for php stuff mod_scgi is fixed Commited the mod_php changes myself... !!! ERROR: dev-php/jpgraph-1.19 failed. !!! Function has_version, Line 194, Exitcode 0 !!! portageq calls (has_version calls portageq) are not allowed in the global scope !!! If you need support, post the topmost build error, NOT this status message. !!! ERROR: dev-php/eaccelerator-0.9.3-r1 failed. !!! Function has_version, Line 194, Exitcode 0 !!! portageq calls (has_version calls portageq) are not allowed in the global scope !!! If you need support, post the topmost build error, NOT this status message. !!! ERROR: net-www/mod_fastcgi-2.4.2 failed. !!! Function has_version, Line 194, Exitcode 0 !!! portageq calls (has_version calls portageq) are not allowed in the global scope !!! If you need support, post the topmost build error, NOT this status message. !!! ERROR: net-www/mod_pcgi2-2.0.1 failed. !!! Function has_version, Line 194, Exitcode 0 !!! portageq calls (has_version calls portageq) are not allowed in the global scope !!! If you need support, post the topmost build error, NOT this status message. mod_fastcgi and mod_pcgi2 done. I'm not touching jpgraph, it's nasty - inherits an eclass based on a has_version. sebastian, you've been a very bad boy. /me gets the whipping stick Do not *ever* conditionally import eclasses. A) it's expressly forbidden B) it doesn't work (depends phase isn't affected by users use conditionals) C) conditionally setting metadata is bad. very very very bad. It doesn't work, either. Correct dev-php/eaccelerator-0.9.3-r1 dev-php/jpgraph-1.19 Looking at those ebuilds, you shouldn't even be using the detectapache hack. For dev-php/eaccelerator and dev-php/jpgraph take a look at their new dev-php4/ counterparts, they are fixed for this and can easily be adapted to work with the old-style PHP support, just wait 5 minutes and I'll attach fixed ebuilds for dev-php/eaccelerator and dev-php/jpgraph. Best regards, CHTEKK. Created attachment 69780 [details]
Fixed dev-php/jpgraph.
This is dev-php4/jpgraph backported for old-style PHP, it's marked as -r1 since
it introduces some new features (notably the "truetype" USE flag).
Best regards, CHTEKK.
Created attachment 69782 [details]
Fixed dev-php/eaccelerator.
And this is the fixed dev-php/eaccelerator.
Best regards, CHTEKK.
Can we make it so that repoman doesn't die when doing a scan for these ebuilds? It makes it hard to scan the whole tree if one package kills it. How's about people fix their stuff in the meantime? :) Making repoman not puke on failed aux_get pulls is rather tricky, although it can be done. Php herd, sebastian isn't doing anything regarding these ebuilds, please step in and fix them (patches provided via chtekk even). Sorry, this must have slipped by me (been on vacation and all). I'll look at it in the morning. Sooner the better, since these ebuilds aren't even sourceable for .53 portage ;) Once corrected, please close the bug, those two are the only remaining ebuilds in the tree affected. :) Thanks Committed the two outstanding patches for dev-php/eaccelerator and dev-php/jpgraph by Luca Longinotti. yank dev-php/jpgraph-1.19 from the tree... Keywording is the same, the ebuild still is horking cache. Done. |