many ebuilds in the www-apps category do not correctly depend on apache (i.e. via depend.apache.eclass) some ebuilds additionally depend on virtual/httpd-php which does not exist. it may also be a good idea to remove webapp-apache.eclass which contains incorrect apache depends as well, and is not use by any ebuild in the tree anymore the following packages use both incorrect apache depends and non-existant virtuals: www-apps/coppermine www-apps/postfixadminvirtual www-apps/zina the following packages use incorrect apache depends: www-apps/bugzilla-2* www-apps/gallery-1* www-apps/gnopaste www-apps/lxr-0.9.5 www-apps/mambo www-apps/metadot www-apps/mod_survey www-apps/moregroupware www-apps/phpwiki www-apps/rt www-apps/sitebar-3.3.9 www-apps/xoops to solve this you can do the following: - hard depends: use one of need_apache, need_apache2 or need_apache2_2 - optional depends: - use one of want_apache, want_apache2 or want_apache2_2 or - include one of ${APACHE_DEPEND}, ${APACHE2_DEPEND}, ${APACHE2_2_DEPEND} in DEPENDS if USE=apache2 is either not wanted or the DEPEND is too complex to solve it with want_apache*
wwww-apps should NOT use depend.apache.eclass unless they absolutely do NOT work with anything else but apache. We created virtual/httpd-basic, virtual/httpd-cgi and virtual/httpd-fastcgi for exactly this purpose. Please use those and NOT depend.apache.eclass unless apache is obligatory dependency.
(In reply to comment #0) > some ebuilds additionally depend on virtual/httpd-php which does not exist. $PORTDIR/profiles/base/virtuals; yeah, we still didn't manage to get rid of old-style ones :)
please take appropriate measures then :)
i found additional webapps (not in the webapp herd), which are broken in a similar way: app-text/refbase (sci) media-sound/mserv (sound) net-analyzer/aimsniff (netmon) net-analyzer/midas-nms (bass) net-analyzer/smokeping (chtekk) net-mail/lurker (net-mail, strerror) <net-mail/mailman-2.1.9-r2 (net-mail, hanno) net-mail/vqadmin (net-mail, robbat2, not yet a webapp, fixed ebuild in my overlay) =net-www/awstats-6.5-r1 (die!) sci-chemistry/webmo (sci-chemistry) sci-geosciences/mapserver (sci-geosciences) sci-misc/boinc (sci, cryos) <sys-power/apcupsd-3.12.2-r1 (base-system, tantive) as jakub told me on irc, some of these are already fixed in the webapp overlay .. if noone else does, i will try to commit them sooner or later
(In reply to comment #0) > www-apps/bugzilla-2* - not touching this > www-apps/gallery-1* - punt it > www-apps/gnopaste - fixed in webapps overlay > www-apps/lxr-0.9.5 - fixed in webapps overlay > www-apps/mambo - fixed in webapps overlay > www-apps/metadot - fixed in webapps overlay > www-apps/mod_survey - fixed in webapps overlay > www-apps/moregroupware - fixed in webapps overlay > www-apps/phpwiki - fixed in webapps overlay > www-apps/rt - not touching this, plus don't see anything wrong with the dependency there > www-apps/sitebar-3.3.9 - r1 is just fine, get it stable on ppc and punt this > www-apps/xoops - fixed in php overlay If someone else on this bug wants me to commit fixed ebuilds not maintained by webapps to the overlay, poke me.
If you could take care of sci-chemistry/webmo (sci-chemistry) sci-geosciences/mapserver (sci-geosciences) sci-misc/boinc (sci, cryos) I'd appreciate it. Thanks, Markus
(In reply to comment #6) > sci-chemistry/webmo (sci-chemistry) - done [1] > sci-geosciences/mapserver (sci-geosciences) - done [2] (*major* ebuild rewrite, please test :P) > sci-misc/boinc (sci, cryos) - can you clean up the redundant versions first please? Not really keen on fixing them all. [1] http://overlays.gentoo.org/svn/proj/webapps/migration/sci-chemistry/webmo/ [2] http://overlays.gentoo.org/svn/proj/webapps/migration/sci-geosciences/mapserver/
Feel free to fix app-text/refbase.
> app-text/refbase - fixed > media-sound/mserv - fixed > net-analyzer/aimsniff - fixed > net-analyzer/midas-nms - fixed > net-analyzer/smokeping - fixed > net-mail/lurker - fixed > net-mail/mailman - not touching this, cannot use APACHE_MODULES_DIR, not a webapp, completely b0rked. > net-mail/vqadmin - fixed > net-www/awstats - bug 208615 > sci-chemistry/webmo - fixed, but fetch-restricted file cannot be downloaded anymore, punt the crap, plz! > sci-geosciences/mapserver - fixed, big thanks to jakub for the ebuild rewrite > sci-misc/boinc - fixed > sys-power/apcupsd - not touching this, my eyes started bleeding while looking at the code. > www-apps/bugzilla - fixed > www-apps/coppermine - fixed > www-apps/gallery - fixed > www-apps/gnopaste - fixed > www-apps/lxr - fixed > www-apps/mambo - fixed > www-apps/metadot - fixed > www-apps/mod_survey - fixed > www-apps/moregroupware - fixed > www-apps/phpwiki - fixed > www-apps/postfixadmin - fixed > www-apps/rt - fixed > www-apps/sitebar - bug 209014 > www-apps/xoops - fixed > www-apps/zina - fixed except where noted i have not opened bugs for your broken ebuilds. all done here. kthxbye.
Reopening since this has not been correctly fixed. As Jakub explained in comment#1 webapps do NOT depend on apache if they don't have to. We use the virtuals virtual/httpd-basic, virtual/httpd-cgi and virtual/httpd-fastcgi for that. I know I'm slow on this but I'll work through the list and get it done eventually :)
@benedikt: Thanks for all patches on the web-apps. They do have a high quality and its great someone improves them. I have one question concerning the issue raised in this bug: You currently mark the ebuilds you fix with "need_php_httpd". I don't see how this pulls in the required web server such as lighttpd, cherokee or apache. As far as I can tell "need_php_httpd" pulls in PHP and thats it. Or am I missing something?
(In reply to comment #11) > As far as I can tell "need_php_httpd" pulls in PHP and thats it. Or am I > missing something? this is correct, i talked to hoffie and jakub and we decided to use need_php_httpd to at least make the ebuild behave correctly, and we only need to fix the eclass as soon as we can check for needed sapis via use dependecies ... but you're right that no webserver will be pulled in now, i think we should add virtual/httpd-cgi to depend.php.eclass as a workaround for the time being ..
Well, what I've been doing is stick both one of virtual/httpd-* and need_php_* to the ebuilds. I'm not really sure that virtual/httpd-* makes any sense in depend.php eclass. need_php_httpd means mod_php which requires apache; need_php_cgi yeah there it'd make more sense.
(In reply to comment #13) > Well, what I've been doing is stick both one of virtual/httpd-* and need_php_* > to the ebuilds. I'm not really sure that virtual/httpd-* makes any sense in > depend.php eclass. need_php_httpd means mod_php which requires apache; > need_php_cgi yeah there it'd make more sense. well, all this is a bit ambiguous IMO, you'd need both need_php_cgi and need_php_httpd in webapps then, as probably most of them work with both setups, still need_php is just plain wrong, since you don't run webapps on the console ... i think it would be a good idea to merge need_php_{httpd,cgi} and just depend on virtual/httpd-cgi ... if mod_php was built, apache has been pulled in anyway, if only cgi is built the dependency is just fine too
As said, due to lacking portage features, it doesn't really matter which for need_php_* stuff you use, each of them at least implies a PHP dependency and that really cannot be dropped. If common sense fails with users (like, ZOMG it sounds pretty obvious what kind of PHP is needed) you could do the following: RDEPEND="virtual/httpd-*" need_php pkg_setup() { require_php_sapi_from apache2 cgi } in the ebuild which implies both correct dependencies and correct php features.
And please note that before "require_php_sapi_from apache2 cgi" could be reasonably used for this, we need to make it honor PHPCHECKNODIE to prevent ebuilds from dying multiple times on php checks.
i thought we agreed on using need_php_httpd for correctness although portage does not yet support the features we'd need to check for sapis (yes, we could hack around that with require_sapi foo, but that's not the correct solution) of course, with this approach, $USER has to take care of the correct php/webserver setup himself, but we would ensure that at least a webserver gets installed by adding virtual/httpd-cgi to need_php_httpd
(In reply to comment #17) > of course, with this approach, $USER has to take care of the correct > php/webserver setup himself, but we would ensure that at least a webserver gets > installed by adding virtual/httpd-cgi to need_php_httpd Well I'm really not sure that depend.php eclass is the place for this dependency, notably since it will imply apache2 for everyone unless they install a different webserver first, even with stuff like USE="-apache2 cli cgi". I can already imagine the bugspam resulting from this.
Created attachment 144210 [details, diff] webapp.eclass.diff wrobel, how about something like this instead?
Created attachment 144212 [details, diff] webapp.eclass.diff Eh, lets not nuke webapp-config dependency :P
Created attachment 144214 [details, diff] webapp.eclass.diff Ugh I definitely need more beer...
Since we mainly support PHP based webapps with webapp-config we could probably have it in depend.php but I agree with Jakub that it would make more sense in the webapp eclass. So this would mean that we would mark most php based webapps with need_httpd_cgi need_php then? @Benedikt: Do you think that would be okay?
(In reply to comment #22) > So this would mean that we would mark most php based webapps with > > need_httpd_cgi > need_php Better make it need_httpd_cgi need_php_httpd so that we are future-proof in case portage grows itself use-based deps soon... :P
ok, in cvs now
this should be fixed