Bugzilla Bug 208584

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 an attachment (id=144210) [edit]
webapp.eclass.diff

wrobel, how about something like this instead?

Created an attachment (id=144212) [edit]
webapp.eclass.diff

Eh, lets not nuke webapp-config dependency :P

Created an attachment (id=144214) [edit]
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