As the summary says, webapp-config should be made optional maybe by making a new USE flag named e.g. webappconf or something like that. If this USE flag is set webapp-config will be installed and webapps are installed using webapp-config, if this USE flag is not set webapp-config is not installed and webapps are installed without webapp-config like before. For more details and the reasons see these forum threads: http://forums.gentoo.org/viewtopic.php?p=1849960 http://forums.gentoo.org/viewtopic.php?t=219887 Reproducible: Always Steps to Reproduce: 1. 2. 3.
As Stu Herbert has indicated in the referenced forum threads, removing webapp-config essentially means the removal of all web applications from Portage. Portage by itself cannot handle what webapp-config does. I sure that is not the intent of this bug's author. It seems that there are two gripes: 1. You have to install webapp-config in order to install web apps. This takes a little bit of space, but in the scheme of things, it is small fry (~200k). 2. When vhost is not in USE, and the /var/www/localhost (or equiv) directory is not on the same partition ast /usr/share/webapps, you get two copies of each web app. This is seen as a heinous waste of space. If the two directories are on the same partition then hard links are used and there is little duplication except where essential to separate configs etc. The requester is asking that emerge webapp install directly into /var/www/localhost (like the "bad old days") in the absence of webapp-config. This might be accomodated in webapp.eclass. When vhost is not set the webapp.eclass could set ${MY_HTDOCSDIR} and friends to point directly into fixed spots in /var/www/localhost and not attempt to run webapp-config at the tail of the emerge. With vhost set, behaviour is as it is now. I don't particularly agree with the author's view of webapp-config and webapp.eclass as hideous impositions. There are obvious problems with fixing the location, such as what happens when you install say phpmyadmin and squirrelmail at the same time. These are no worse than the pre-webapp-config days (but they are what webapp-config was designed to fix). I must stress that I haven't actually studied the feasibility of this in a coding sense.
At this time, there are no plans to drop support for webapp-config. Best regards, Stu
