While preparing to run an update (`emerge --update --upgradeonly --deep --pretend world`) recently, I noticed that portage wanted to install apache--even though I purposefully omitted the apache1 and apache2 flags from my USE flags (I have no need for a web server on my machine). Apparently, there is some problem in the webapp-detect function/class that leads portage to conclude that I have, or want, a web server installed.
The htdig ebuild really shouldn't be using the webapp-apache eclass if we're supporting installs of htdig without apache being present. It's something that we need to fix. Stu
Re-assigning to mholzer - it was his change that caused this bug.
peoples - I'm currently attempting to make a webapp compliant htdig without the dependancies for apache. Wish me luck ;-)
stuart the next bug with webapp.eclass ? >>> sym buttonr.png >>> sym button10.png >>> sym htdig.png >>> sym star.png >>> sym star_blank.png * Installing from /usr/share/webapps/htdig/3.1.6-r5/hostroot >>> sym /var/www/localhost/cgi-bin/htsearch /usr/sbin/webapp-config: line 237: /var/db/webapps/htdig/3.1.6-r5/installs: No such file or directory * Install completed - success
Created attachment 30632 [details] htdig-3.1.6-r5.ebuild
Okay, I'm looking at it right now ;-)
Okay, this is caused by bugs in the ebuild. Inside src_install(), the second line is a call to 'webapp-pkg_install'. This function doesn't exist. At the end of src_install(), there's no call to 'webapp_src_install()'. I'll add something in webapp_pkg_postinst() to detect that. Also, webapp ebuilds shouldn't set SLOT. The eclass takes care of that. I've added a warning to catch that. I'll have to commit the changes to the eclass when emu comes back :( Best regards, Stu
Stu - no emu but lark is waiting ;-)
Converted to use webapp.eclass, in CVS, shouldn't pull in Apache anymore
closed
