Reporting this as promised: virtual/httpd (or however you want to call it) would be very neat for a lot of packages. In fact, virtuals like virtual/httpd-php would be useful either. -phoen][x-
yes, its still a good idea ;-) sooner or later!
*** Bug 3384 has been marked as a duplicate of this bug. ***
i've found in webapp-apache DEPEND="${DEPEND} net-www/apache" how about rename this eclass or split it or update it with virtual/httpd
the webapp-apache eclass was commited the tree by one person but the rest of us never intended to fully use it, the change can be made as a stopgap measure, but in general we are doing the vhost-config and webapp-config tools first, as they will have new eclasses to go with them.
As the author of webapp-apache :) I'd just like to echo what Robin said. webapp-apache is a stop-gap, to allow me to fix bugs with existing packages. We will be replacing it with a different solution very soon. Best regards, Stu
i don't want that is closed as wontfix. there are many new ebuilds in bugzilla which provide a webserver. i just want to provide "virtual/httpd" for every package which could run web-apps.
You're right - we need to go through all the web-server ebuilds and update them to provide "virtual/httpd". Stu
how about this one ?
mholzer: we haven't forgotten about this. webapp-config et al are still work in progress (after my exams)
Is it possible to install more than one package providing a virtual? Background of the question: I feel that it should be possible to install more than one httpd at a time and if a "virtual/httpd" blocked that it would be a bad thing. Anyway: if the "virtual/httpd"-modifications get real I'm willing to do that for mini_httpd and the pending thttpds I submitted in bugs #36173, #36175, #36177.
*** Bug 41942 has been marked as a duplicate of this bug. ***
virtual/httpd-php has been created.
reassigning
I'm also interested in that. It would allow to install some apps without installing apache when using an alternative webserver. I've had a bug filed for awstats ( #96154 , https://bugs.gentoo.org/show_bug.cgi?id=96154 )which I can't install without installing apache with it. Is there any chance to get this implemented sooner (and not later ;)) ?
So? People still keep complaining about hard-coded apache dependencies...
*** Bug 119118 has been marked as a duplicate of this bug. ***
Stuart is taking the lead on this from the web-apps end of things. We'll start pushing for this soon.
We need to have a discussion to figure out what exactly we want from the virtual. What would the packages that provide the virtual be required to provide? Not all HTTP servers are built equal, and most have vastly different configurations. I could see a virtual working for most webapps, but any that need a custom server configuration could get tricky. How many webapps would have to depend on apache directly because they need a .htaccess to work? I'm sure there are many other corner cases like that. Let's flesh this out to see what the virtual will really do.
(In reply to comment #18) > We need to have a discussion to figure out what exactly we want from the > virtual. What would the packages that provide the virtual be required to > provide? Not all HTTP servers are built equal, and most have vastly different > configurations. I could see a virtual working for most webapps, but any that > need a custom server configuration could get tricky. How many webapps would > have to depend on apache directly because they need a .htaccess to work? I'm > sure there are many other corner cases like that. Let's flesh this out to see > what the virtual will really do. Certainly. I've started to put together a matrix of http servers and proposed virtuals: http://devwiki.gentoo.org/tiki-index.php?page=virtual%2Fhttpd It will need to be fleshed out, but at least that's a start. We'll keep you and the www-servers herd in the loop.
(In reply to comment #18) > We need to have a discussion to figure out what exactly we want from the > virtual. What would the packages that provide the virtual be required to > provide? Not all HTTP servers are built equal, and most have vastly different > configurations. Well, no need to depend on the new virtuals for packages that require a specific functionality, there you can still use something like || ( net-www/apache www-servers/lighttpd ) or even depend on apache only, if needed. As for configuration, I don't see that providing configuration for *all* servers providing the virtuals to be within the scope of this bug (would be indeed impossible), it still users' responsibility mostly. (In reply to comment #19) > I've started to put together a matrix of http servers and proposed > virtuals: http://devwiki.gentoo.org/tiki-index.php?page=virtual%2Fhttpd Uhm, this is certainly too broad for start. :=) Meanwhile, a really simple "new-style" virtual/httpd including only apache and lighttpd would do the job for quite a couple of webapps in portage, I believe those two web servers are most widely used and tested anyway. You can keep adding others later.
*** Bug 121163 has been marked as a duplicate of this bug. ***
I was the one to issue the duplicate bug above :-/ I guess my search skills in bugzilla need some improvement. Anyway, I agree that matrix of virtuals proposed on the wiki is probably the way to go. Just to clarify things, the suggested virtual/httpd-<language> (where language=python, perl, ...) would refer to webservers able to power web app written in <language> by other means than cgi or fcgi? Maybe that's something already clear to everyone, but until not so long ago it was not to me, so I'd also like to point that the present virtual/httpd-php does NOT cause a websever to be there. It guaranties that a cgi capable php is around, but not that there is a web server to make it run. Or so I understand. Is that really what we want?
*** Bug 121228 has been marked as a duplicate of this bug. ***
Mmm ... let's take a step back, and have another look at the problem? The need behind virtual/httpd is to allow web-based apps to have something that can be used for (R)DEPEND. In an ideal world, the dep could be reduced to something as simple as this: RDEPEND="virtual/httpd virtual/httpd-<language>" That's not going to work, unfortunately, for a number of reasons. a) Portage doesn't support optional PROVIDEs. F.ex, dev-lang/php needs to PROVIDE virtual/httpd-php ONLY if it has been built with USE=apache, USE=apache2, or USE=cgi. The new virtual packages that are coming w/ Portage 2.1 don't solve this problem either, unless Portage 2.1 also supports USE-based deps. b) Do packages for web-based apps need to know whether or not they are running under an Apache module (mod_php, mod_perl, mod_ruby) or under a CGI interpreter instead? PHP packages don't need to know, but trac is an example of an app that does need to know, or at the very least could make use of that information. c) All of this continues to overlook whatever the hell it is we need to do to support Java-based web apps, running in a servlet/JSP environment like tomcat, or a full-blown J2EE stack like JBoss. I'm not sure that we can solve these problems using virtual/httpd, even with USE-based deps support. I think the best we can do is to push the per-language support down into web-based apps (via a set of depend.<language>.eclass), and push each language's particular needs for a compatible webserver down into the ebuilds for that language. In theory, that would allow us to do away with a virtual/httpd completely. For example, a PHP-based web app's ebuild could look something like this: inherit depend.php RDEPEND="dev-lang/php" pkg_setup () { php_provides_http || die "PHP was not installed for a web server" } where php_provides_http does whatever checks are meaningful, and also outputs a suitibly verbose error message if those checks fail. This example doesn't address the second problem - is the language setup to run as a CGI or as a webserver module. That one is tough to solve; on a production box, it's perfectly possible for both cases to be true. We also don't know *which* webserver is being used - and we need to know, otherwise webapp-config cannot install the files with the correct permissions. webapp-config only needs to know about the setup for localhost; for all other hosts, the user has to run webapp-config by hand, so for now we can make that a special case that we expect the user to solve. But how can we find out about which server is looking after localhost, and how the language is configured to run for localhost? Best regards, Stu
*** Bug 125574 has been marked as a duplicate of this bug. ***
*** Bug 127081 has been marked as a duplicate of this bug. ***
*** Bug 130723 has been marked as a duplicate of this bug. ***
I'm attaching depend.httpd.eclass that attempts to provide a solution. Ebuilds can call the use_httpd function to depend on a fastcgi-capable webserver such as lighttpd instead of Apache. For example, "use_httpd fastcgi cgi" means that the web application can be run as a plain CGI or FastCGI. If Apache is installed, it will be used. If you don't want Apache and have another webserver installed (eg lighttpd), set USE="fastcgi" and the RDEPEND will be satisfied by lighttpd. If you want an even more basic webserver (eg fnord), emerge it and set USE="cgi". If no relevant USE flags are set, we assume the user knows best and nothing will get pulled in. If you don't want to be bothered by the new USE flags, just emerge Apache and leave it be. An obvious caveat is that we can't be sure that the available httpd is emerged with the right USE flags. For now, I think it's fine to assume that the user will take care of that. There are further comments in the attached eclass. > We need to have a discussion to figure out what exactly we want from the > virtual. What would the packages that provide the virtual be required to > provide? Not all HTTP servers are built equal, and most have vastly different > configurations. As Jakub said, the ebuild should depend on Apache explicitly if Apache-specific functionality is required. > As for configuration, I don't see that providing configuration for *all* > servers providing the virtuals to be within the scope of this bug (would be > indeed impossible), it still users' responsibility mostly. +1 > b) Do packages for web-based apps need to know whether or not they are running > under an Apache module (mod_php, mod_perl, mod_ruby) or under a CGI > interpreter instead? PHP packages don't need to know, but trac is an example > of an app that does need to know, or at the very least could make use of that > information. I think we should leave this up to the user to configure. > c) All of this continues to overlook whatever the hell it is we need to do to > support Java-based web apps, running in a servlet/JSP environment like tomcat, > or a full-blown J2EE stack like JBoss. True, but I don't think this is a show-stopper. AFAIK, there are no Java webapps in the tree atm. In any event, I have a feeling that Java webapps will be handled outside of webapp-config, probably building on existing projects such as Cargo [ http://cargo.codehaus.org/ ] Comments? Do people think this is a reasonable way forward?
Created attachment 90815 [details] depend.httpd.eclass
Created attachment 90816 [details] joomla-1.0.10-r1.ebuild Sample ebuild using the new eclass.
CHTEKK pointed out that php does not have a fastcgi USE flag, so the test ebuild is incorrect in that aspect (I swear I saw it last night...) The point I was trying to make is that the ebuild can perform cgi- / fastcgi-specific checks if necessary.
Looks all good to me. :) Best regards, CHTEKK.
*** Bug 140333 has been marked as a duplicate of this bug. ***
*** Bug 143530 has been marked as a duplicate of this bug. ***
web-apps/www-servers: can somebody propose this eclass on -dev so that we can get it into the tree finally?
God no. Please please _please_ don't do that. The live tree is not the place to be experimenting with something like this. Let's not create another webapp-apache! Create a branch in the webapps overlay on o.g.o, import the ebuilds from Portage, port them to use this eclass, and test them (all packages will need testing with all compatible web servers) When we've done that, _then_ we'll have a good idea whether or not this is really sustainable. Tbh, I'd also be much happier about this virtual if all compatible webservers installed themselves to run under a generic 'www' user instead, before we start providing virtual/httpd. Best regards, Stu
Finally got around to looking at the eclass myself. It needs to be refactored, as it breaks the cache. You can't conditionally change RDEPEND based on USE flags, as the USE-flags on the cache-generating server will not be the same as the ones on the user's system. You have to put the USE-flag in the RDEPEND directly.
*** Bug 157040 has been marked as a duplicate of this bug. ***
Created attachment 105342 [details] virtual/httpd-fastcgi-0.ebuild Nevermind the eclass then. Why can't we just use new-style virtuals for this? I've attached virtual/httpd-fastcgi, and we could also have virtual/httpd-cgi and virtual/httpd-basic. Each will pull in Apache by default, but will use whatever webserver (such as lighttpd) that is installed locally if it is sufficiently capable. Thoughts?
phreak`` has added the three virtuals to the apache overlay: http://overlays.gentoo.org/proj/apache/browser/testing/virtual The Apache team (CHTEKK, kloeri, phreak``) have signed off on this.
This is all OK with me.
Added virtuals to the webapps overlay: http://overlays.gentoo.org/proj/webapps/browser/experimental/virtual I also added www-apps/otrs and www-apps/rt that utilize virtual/httpd-fastcgi
since it's been a month with no objections, i'm planning to add the three virtual to the tree. speak up now
Well, ping! I've switched the whole webapps overlay to use these virtuals, and it's *lot* better than the current situation, so - can we just finally get this in?
Finally in portage. Thanks to Renat for providing these and to Jakub testing and nagging me about it.
