This line is INCORRECT: local DocumentRoot="`grep '^DocumentRoot' /etc/apache/conf/apache.conf | cut -d\ -f2`" if you have virtualhosts in your apache.conf (not everyone is willing to use vhosts.conf gentoo convention), you can have multiple lines that begin with "DocumentRoot", so the variable ends up assigned with all of them. What about adding a "|head -1" to the end, or installing it into a /usr/local or /opt subdir and leave to the user to make the link? Reproducible: Always Steps to Reproduce: 1. put some lines in your apache.conf that begin with DocumentRoot (for example: Virtualhosts) 2. emerge phpmyadmin 2.4.0 3. Actual Results: The ebuild put PHPMyAdmin directly in my documentroot, overriting the index.php file Expected Results: To put it into documentroot/phpmyadmin The phpmyadmin version is 2.4.0 Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.19-gentoo-r9 i686 AMD Duron(tm) processor GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 3dnow crypt gif jpeg libg++ mmx ncurses nls png truetype xml2 zlib gdbm berkdb slang readline gpm tcpd pam ssl python -apm -arts -avi -cups -encode gd -gnome -gtk imap -imlib -java -kde -libwww maildir mbox -mikmod -motif -mpeg mysql nocardbus -oggvorbis -opengl -oss -pdflib perl -qt -quicktime sasl -sdl snmp -spell -svga tiff -X -xmms -xv" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -mcpu=athlon-xp -O3 -pipe" CXXFLAGS="-march=athlon-xp -mcpu=athlon-xp -O3 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
woodchip: if this is right, every ebuild that does this has to be updated what do you think about this ?
remove the crud before DocumentRoot="/home/httpd/htdocs". this is the bonifide place to install it. the code for grepping on ^DocumentRoot was spammed by a junior developer whom i asked to unspam it, alas it looks like it wasnt in this case.
I added the DocumentRoot code at Martin's request. I copied it from another ebuild, but I can't remember which one. The following packages use exactly the same method of determining DocumentRoot and so will also suffer from this bug: app-office/phprojekt dev-db/mysqltool net-analyzer/cacti net-mail/squirrelmail net-www/phpBB We need a standard way of determining where DocumentRoot is. I suggest that we use the grep apache.conf hack unless DOCUMENT_ROOT= is set in the environment in which case that is used instead, e.g. emerge phpmyadin # uses grep on apache.conf/apache2.conf DOCUMENT_ROOT=/my/doc/root emerge phpmyadmin # uses /my/doc/root Eloi, would this be sufficient for you?
Have put fix in CVS. Please test.
Tom, does this not mean that a prebuilt phpadmin (and those other packages as well) can only be installed on the same box it was built on, and even then only if /etc/apache/conf/apache.conf remains unchanged? Is an ebuild supposed to analyze the build host configuration at build time? I would think not, and I agree with Donny that a deterministic location would be the right thing to use.
After thinking some more about it, /home should be reserved for real users. What about /var/httpd, also as home directory for httpd in /etc/passwd? Same for user ftp?
sf, there would be a problem with pre-built phpmyadmin packages if the build machine uses a non-standard DocumentRoot (i.e. not /home/httpd/htdocs). Personally I would be in favour of ALWAYS using /home/httpd/htdocs as the doc root. Supporting a per-installation docroot is always going to be messy. I think /home is a good place for it, rather than /var. /home tends to get more backup attention than /var. Furthermore since HTML docs tend to be created by a human it is effectively a real user's home directory.
Tom, you seem to agree not to guess a location, so I think all attempts to guess one should be dropped, at least in the long run, with an appropriate warning from now on. I still disagree about httpd's default home directory, but if DOCUMENT_ROOT were used everywhere instead of "/home/httpd" (even for httpd's entry in /etc/passwd) I could well live with it. Here is a list of packages that have "/home/httpd" hardcoded (find /usr/portage/*-*/ -name "*.ebuild" | xargs -r grep -l /home/httpd | xargs -r -n1 dirname|sort -u): /usr/portage/app-admin/modlogan /usr/portage/app-admin/webalizer /usr/portage/app-doc/dox /usr/portage/app-games/uglygs /usr/portage/app-misc/gallery /usr/portage/app-misc/lhinv /usr/portage/app-office/phprojekt /usr/portage/dev-db/mysqltool /usr/portage/dev-db/phpmyadmin /usr/portage/dev-db/phppgadmin /usr/portage/dev-perl/AxKit /usr/portage/dev-php/phpgroupware /usr/portage/dev-php/phpsysinfo /usr/portage/media-video/xawtv /usr/portage/net-analyzer/cacti /usr/portage/net-analyzer/snorticus /usr/portage/net-analyzer/snortsnarf /usr/portage/net-mail/squirrelmail /usr/portage/net-misc/bk2site /usr/portage/net-misc/linesrv /usr/portage/net-misc/nut /usr/portage/net-www/adzapper /usr/portage/net-www/apache /usr/portage/net-www/boa /usr/portage/net-www/cvsweb /usr/portage/net-www/horde-chora /usr/portage/net-www/horde-imp /usr/portage/net-www/horde-kronolith /usr/portage/net-www/horde-turba /usr/portage/net-www/htdig /usr/portage/net-www/moinmoin /usr/portage/net-www/monkeyd /usr/portage/net-www/phpBB /usr/portage/net-www/squidalyser /usr/portage/net-www/viewcvs /usr/portage/sys-apps/apcupsd
As somebody that handles several of the listed packages (both for the automatic detection and for the ones with static paths), I have another suggestion. For the document root, I think we should just install to the static path, as this is what the great majority of the users will be using. We then display a message for all users telling them they can symlink /home/httpd/htdocs/foo into whichever of thier virtual hosts or other web directories they want them in. This makes it easier for us to keep things clean, and less work for us to come up with detection code. I personally have /var/www/[domainname]/[host]/ for my virtualhosts (7 domains, 27 hosts in total). I let all ebuilds install to /home/httpd/htdocs/ still, and symlink any application I need into the tree wherever it is needed.
> Personally I would be in favour of ALWAYS using /home/httpd/htdocs as the doc > > root well why are you going against what I said on a thousand occasionts then? i decided this crap a long time ago people. /home/httpd/htdocs is THE DocumentRoot for extra ebuilds to install stuff to. /home/httpd/cgi-bin is THE place to put cgi-bin programs. /home/httpd is THE --datadir. i dont want automatic detection crap in the ebuilds. please stop making me repeat my over anad over again. if you really want to change the locations of these things its not THAT hard to do it with some perl or sed -i etc. The string "/home/httpd" being in the ebuilds is great because you can easily find WHAT you might want to change, as was already indicated and indeed thats always been part of the idea anyways. i do not really like automatically screwing around with peoples config files either, like the apache-1 ebuild does with users' apache.conf files, and the 'ebuild ... config' mumbo/jumbo. the apache-2 way is much simpler. look, its really simple -- there should be a bonifide place to put these things -- and you already know where it is: in /home/httpd/{htdocs,cgi-bin} the /var/www thing is old news as well. no, its not goint to be changed. yes, i've already been over this a thousand times as well. it works fine for >=%90 of the users, and for anybody else who needs it changed, they have only minor config file editing to do. there is no standard for this in FHS, we like /home anyays, blah, blah, blah. really its junior developers who think they speak for the entire team that is the problem. you tell them something, they dont listen. they think they know it all, yet they havent been around on the team for 2 years going over all this stuff again and again and again. remove that spammed grep ^DocumentRoot crap please, for the umpteenth time. and what if somebody has apache-1 AND apache-2 installed, operating from different global datadirs and documentroots? you are away i took much time and effort to create the Gentoo Apache ebuilds such that they're both SLOTted and can be installed alongside each other fairly painlessly you only need to understand how to maintain your configuration files. there will be no guessing where the user wants the junk installed, they shold go to where the bonifide location is.
Now always install to /home/httpd/htdocs.
OK. Static and global standard is the best solution : you know what the ebuilds are supposed to do on ANY system. Anyway, there are people around that don't even use Apache, so it's worthless to guess what the DocumentRoot is for everyone.
OK. Just remerged phpmyadmin, and it seems solved. Anyway, the ebuild code is simpler and more deterministic, so it's pretty difficult to screw things on other machines. Just a proposal : wouldn't this be a nice env.d setting?
Resolution lost by bugzilla
New version, same bug. Now, by the hand of webapp-apache.eclass. Could it be possible to KILL the fucking buildtime documentroot (incorrectly) guessing for ever? Or if someone has the inner need of implementing it, could he/she put a simple "head -1" at the end of the pipe AND make this an option defaulting to not make the guess? How lucky of us that the authors of webapp.eclass don't even consider implementing the documentroot guessing "feature".
Eloi, the documentroot stuff has been a bother, this is true. Hopefully there is light at the end of the tunnel. The web-apps herd is pretty small and there much, much work to do. Perhaps youd have interest in becoming a free software volunteer, like the rest of us, and work for free to please the users of our great distribution for nothing other than a enjoyment of doing the work? If you're interested in joining us, and helping to do all of this work, join the irc channel and speak to somebody about it. Thanks.
maybe don can help
While it might not please all, I could care less where the DocumentRoot it. It changed with the newer apaches, so I dealt with it. Yes there will be issues when upgrading from a pre-change version to a post-change version. Issues for users that come to mind are web admins will have to copy any customizations to the new DocumentRoot. Issues for devs are obviously having to make revisions of the packages for the new GLEP #11 situation. So that was my non-user-friendly response.
I'll join to the irc channel. By the way, which one? #gentoo-dev is moderated... may I privmsg to anyone of this thread? Or do I join #gentoo-user? Don, I don't care where the default DocumentRoot is. It would be nice, however, that when it is changed a huge warning is put in the apache.conf file so we can adapt our aliases, rewrite rules, etc to it. What I do complain is the flawed documentroot detection code in ebuilds and in webapp-apache.eclass that first trashed my documentroot, and now creates a directory like "documentroot\nvirtualdocumentroot1\nvirtualdocumentroot2..." and fails to install the application. Sorry, but this is a BUG. Couldn't anyone make a policy of what to do while webapp.eclass isn't ready? I thought woodchip made it clear that no path autoguessing on build time should be done, but it seems it's not so clear now (at least for webapps package maintainers).
closing this one has it works as expected. please use bug #30607 for ideas/problem reports
webapp.eclass and webapp-apache.eclass aren't the same eclass. This ebuild uses, for now, webapp-apache.eclass. So IMHO webapp.eclass isn't the point now. And the DocumentRoot guessing IS BROKEN. VirtualHosts may go to a separate file, or may not. The directives may be indented, or may not. In the case of webmin: putting virtualhosts in a separate file didn't work well (I don't know if it already works by now), and it doesn't indent the directives. I believe this won't be the only software behaving this way out there. webapp-apache.eclass, in it's current incarnation, given that scheme creates a directory like documentroot1\ndocumentroot2\ndocumentroot3\n... and fails to install the webapp. Well, we should thank god it doesn't overwrite existing DocumentRoots anymore. It misleads xdiskusage parsing, for example, but then you get aware of the problem, manually fix webapp-apache.eclass one more time, and remerge the package. I suppose I'll exclude the eclass from rsync. But well, if that's is "working as expected", nothing more to discuss. Sorry for the inconveniences and wasting your time. I'll wait for webapp.eclass for being done (and if there is any way to help aside of joining IRC, I may try to help a little).
