Summary catch your attention? ;) As y'all know, the nondetermenistic setting of SLOT based upon has_version doesn't really work for buildplan creation (iow, portage can and will screw up the plan of what to do). That said, a portage loophole in metadata handling allows metadata to be changed after the fact, affecting binpkg and vdb installations. This is why it sort of works for dev-php/mod_php, and net-www/mod_scgi after they've been installed. portageq, which has_version relies on, will be converted into an immediate failure if called during metadata sourcing stages. The reasons behind it pretty much come down to the fact has_version calls don't work the way people are attempting (nor will they ever) for setting metadata. dev-php/mod_php's ongoing migration should remove the need for the slot hack afaict; mod_scgi, well, y'all are going to need to come up with a plan to move away from the slot hack- next version of portage *will* fix the shoddy code that allows the changing of SLOT after the fact to work, so it's death is coming. Either way, attached are patches to make mod_php and mod_scgi survive the upcoming disabling of portageq during depends phase- they hard code apachever to 1, just the same as what happens already for all rsync users (I say 'hardcoded', due to the fact osprey which generates the cache, always generates the slot=1). So... the patches will make it deterministic for setting SLOT for depends phase, while preserving the old behaviour. Aside from that, this type of code should not appear anywhere else in the tree; I'm not particularly happy mod_scgi picked it up also, since it's a longstanding QA violation (one hard to change after the fact) :) </stern voice> Sooner you can get these into the tree, the better. Next minor version of portage is going to break the current form of the ebuilds in the tree (so it's in your interest to get these suckers in). If you've got questions, give a yell; these patches just hardcode the existing behaviour, no change, but I can fill in the gory details of cache handling if you want it.
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.
