the directory for apache-1.x is /etc/apache Calculating dependencies ...done! >>> emerge (1 of 1) net-www/phpBB-2.0.5 to / grep: /etc/apache1/conf/apache1.conf: No such file or directory >>> md5 src_uri ;-) phpBB-2.0.5.tar.gz grep: /etc/apache1/conf/apache1.conf: No such file or directory * Installing for Apache v1 Caught signal 2 Killed Reproducible: Always Steps to Reproduce: 1. 2. 3.
Hi Carlo, I've added a fix for this to webapp.eclass v1.6, which should be hitting the rsync servers within the hour. Please test this, and let me know how you get on. Best regards, Stu
thx, works - next small bug: >>> Merging net-www/phpBB-2.0.5 to / /usr/sbin/ebuild.sh: line 1: webapp-apache_pkg_preinst: command not found btw.: I test it only for apache-1. I really don't want to install apache-2, yet.
Could you add webapp-apache_src_compile() { #we need to have this empty function ... default compile hangs echo "Nothing to compile" } EXPORT_FUNCTIONS src_compile Ebuilds like phpBB or davedap (not yet in portage) doesn't need to add this function again and again, while others can supersede it.
Adding something like ${HTTPD_ROOT}/${PN_downcase} instead of ${HTTPD_ROOT}/phpbb in pkg_setup() it should be possible to move this funtion to the eclass, too. But I'm not sure, if it's good to hide this funtion in an eclass.
Okay, found that. Fix is in webapp-apache.eclass v1.7, should be on the rsync servers within the hour. I'm not going to add the src_install() to the eclass, as not all ebuilds have nothing to compile. Best regards, Stu
*** Bug 25976 has been marked as a duplicate of this bug. ***
>I'm not going to add the src_install() to the eclass, as not all ebuilds have nothing to compile. I really don't understand this, Ebuilds that _not_have_nothing_ to compile can easily override the inherited function. Maybe I'm a dumb idiot and it is intended, but according to http://www.gentoo.org/doc/en/eclass-howto.xml#doc_chap1 you only get the proper inheritance/export functionality, if the functions you want to export are named eclassname_functionname() eg. webapp-apache_pkg_setup() instead of webapp-pkg_setup () I could add another eclass with two samples to show you if appreciated!? In my eyes the current eclass implementation is wrong, otherwise enlighten me please. ;-)
Hi Carlo, An eclass is just a bash shell script, and any functions defined in the eclass can be called from an ebuild, no matter what they are called. The reason that the functions are *not* called webapp_apache_* is because, in future, I may supply another eclass to support the same functionality for different webservers. Think about it. An ebuild that calls webapp_apache_* explicitly needs modifying extensively to support, say, webapp_tux_*. But, if the functions in the eclass are just called webapp_*, then the ebuild only needs to pull in the correct eclass for the webserver. Yes, I'm deliberately subverting the documentated way that eclasses are supposed to behave - but that's because, in this case, I believe this way is closer to the spirit of why eclasses were invented in the first place. As to src_compile() ... right now, none of the ebuilds that rely on webapp-apache.eclass have anything to compile. I'd rather add a webapp-c.eclass, and a webapp-perl.eclass and so on to provide re-usable configuration and compilation functions. webapp-apache.eclass is all about the apache part of installing a webapp; if it was meant to be more general, I'd have called it webapp.eclass. Once GLEP 11 has gone through (see the discussion in the gentoo-dev mailing list archives, and http://glep.gentoo.org), the webapp-apache.eclass will probably be deprecated anyway. Best regards, Stu
Hi Stuart, thanks for long answer. I had not time to read the GLEP and the discussions by now, but I'll do it for sure. Another one: fowners "$HTTPD_USER"."$HTTPD_GROUP" "$HTTPD_ROOT" in function webapp-determine-htdocsdir () If apache had a security problem, it could delete "$HTTPD_ROOT"/* I'll prefer it, if the directory is owned by root.
I appreciate the problem, but some web apps need to be able to write to directories under $HTTPD_ROOT. When we roll out the new way of doing webapps, most of the directories *will* be owned by root, with only writable ones owned by the webserver. Hope you don't mind, but I'd rather push on with getting the new way of handling webapps done, so I've got a long-term solution to port all the existing ebuilds to. Best regards, Stu
Hi Stuart, hope you don't expected a fast answer. I'd like to see these ownership problem solved in the rewritten webapp eclass. Read some interesting #gentoo-dev discussion about it? When will be there? Soon!? If not - could you have a look at bug #26808? The bug describes a general webapp-apache.eclass/userpriv problem. Thx! :)
Hm, don't mind the first question mark. I rearranged the sentences a little and lost it somehow. ;)
Another bug in fowners line: Change '.' to ':' fowners "$HTTPD_USER":"$HTTPD_GROUP" "$HTTPD_ROOT"
This bug shows up "Status: NEW" to me, however the activity tells me CLOSED. There is something wrong.
Hi Phil, You're right - that shouldn't happen. I've copied this in to our bug-wrangling team, in the hope that they can look into it, and see what's wrong with our bugzilla database or code. Thanks, Stu
this happened in the bugzilla oops from not too long ago
