Summary: | Policy violation: squirrelmail | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Honter Zoltan <huge> |
Component: | New packages | Assignee: | Jeremy Huddleston (RETIRED) <eradicator> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alpeterson, langthang, web-apps |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 33466 | ||
Bug Blocks: | 41289 | ||
Attachments: |
rewored squirrelmail ebuild
squirrelmail-1.4.2-r5.ebuild still minor tweak 4895-squirrelmail-1.4.3_rc1-r1.log |
Description
Honter Zoltan
2004-02-28 14:09:31 UTC
To fix this, someone needs to update the squirrelmail ebuilds to use the new webapp eclass. Best regards, Stu Created attachment 30315 [details]
rewored squirrelmail ebuild
just reworked the ebuild to use webapp.eclass
some minor tweaks are still needed.
Stuart: show about commiting webapp.eclass ebuilds with a new SLOT ? webapp.eclass automatically puts builds into SLOT=${PVR}. That's going to cause us some problems - but that's for another bug ;-) Best regards, Stu Created attachment 30437 [details]
squirrelmail-1.4.2-r5.ebuild
please test this and write your opinion The only comment I have is about pkg_postinst(). If the user has USE=vhosts enabled, they have to manually run webapp-config to install squirrelmail under the correct host. If you use webapp_postinst in your ebuild to install post-installation instructions, these users will get the instructions when they run webapp-config by hand. Also, webapp-config provides full CONFIG_PROTECT support for config files. The ebuild could install the config file, instead of the user having to do it by hand. Otherwise, it looks good. Best regards, Stu Can you please test squirrelmail-1.4.2-r5 that is in portage right now. I reqrote it to use the new webapp eclass and waited for bug #48962 to be resolved before committing it... Reassigning this bug to me as I'm the squirrelmail maintainer ok... I looked through the differences between Martin's and my versions to see if I missed anything, and I see he added index.php and data to the server owned... I missed that, so I've updated my version in portage accordingly... and I also threw data into config so it would be made per vhost. Not revbumping as it is a fairly new ebuild, is marked unstable, is a small tweak, and a version bump will be here shortly to address security bug #49675... but please check that you have 1.4.2-r5 version 1.2 (cvs version in the $Header) when you test it out. Thanks. Created attachment 30505 [details, diff]
still minor tweak
Thanks, Martin. I just committed those changes except for one... Is it really neccessary to have config_default.php and config.php? you could always get the default files by looking in /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs/config since plugins-config is also moved, the ebuild looks quite good for me two problems: 1. where is the warning that squirrelmail has moved to /usr/share/webapps? Not until I try `qpkg -l squirrelmail` 2. # emerge squirrelmail <snip> * /usr/share/webapps/squirrelmail/1.4.2-r5/hostroot/icons; skipping * squirrelmail-1.4.2-r5 does not install from * /usr/share/webapps/squirrelmail/1.4.2-r5/hostroot/error; skipping * Linking in required files * Installing from /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs * Install would overwrite existing file /var/www/localhost/htdocs/squirrelmail/po/compilepo Fatal error(s) - aborting * Caching service dependencies... >>> net-mail/squirrelmail-1.4.2-r5 merged. >>> clean: No packages selected for removal. >>> Auto-cleaning packages ... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. Should I be concern with the "Fetal error" above? I have no problem login and read mail. I believe the "fatal error" was because it tried to install squirrelmail to that location, but you already had a copy there... webapps guys wanty to comment on that... as fot the first comment, I removed it because of Martin's suggestion (see comment #11) warning could be done in src_unpack but please don't use pkg_postinst() src_unpack is never called for binary installs, though... pkg_postinstall is where information to the user is displayed. The warning about not calling webapp_src_install() can't be caught any earlier than webapp_pkg_postinst(). Unless you can suggest a way? The fatal error - as Jeremy said - is because you already have an installation of squirrelmail in /var/www/localhost/squirrelmail. I'm concerned about this fatal error, because portage should have already removed your existing copy before the eclass calls webapp-config. I'll do some testing on this tonight. Squirrelmail hasn't moved to /usr/share/webapps. What goes in /usr/share/webapps is a non-executable master copy, which is cloned using the webapp-config tool. Best regards, Stu What I did was: I have a working squirrelmail located at /var/www/localhost/squirrelmail (Gentoo Virtual Mail guide). After an update to squirrelmail-1.4.2-r5, I try to login //localhost/squirrelmail/, it throw me a 403 forbidden (because index.php is no longer exist in /var/www/localhost/squirrelmail?). I thought that I missed some warnings so I emerged squirrelmail again and saw the "fetal error". In order to get squirrelmail working again, I created a softlink '/var/www/localhost/mail' point '/usr/share/webapps/squirrelmail/1.4.2-r5/htdocs' and login with //localhost/mail/. I don't know what is the right way after all of these change. May be the docs team will update the guide in the future would help? That's an interesting solution ;-) The best thing to do is to rename /var/www/localhost/htdocs/squirrelmail to something else, then emerge squirrelmail once more. That should put everything where it needs to be. Note: your Apache document root should be /var/www/localhost/htdocs - and not /var/www/localhost. It's an important difference. There are (and will be more) ebuilds in the tree that expect to install files into other directories under /var/www/localhosts. I agree - we haven't fully understood the impact that webapp-config would have. We'll definitely try and learn for the future. Best regards, Stu OK. So I renamed /var/www/localhost/htdocs/squirrelmail then emerged squirrelmail again. One thing that I noticed is the new ebuild broke `qpkg`. The ebuild put "stuff" in /var/www/localhost/htdocs but `qpkg -l -nc squirrelmail | grep var` didn't pick it up. Then I try `emerge -C squirrelmail`, as expected, the ebuild doesn't clean '/var/www/localhost/htdocs/squirrelmail' either. There are no plans to make webapp-config compatible with qpkg. Personally, I'd love to, but there's no way to tell Portage about the files that webapp-config installs, and the Portage team are not supportive of the idea either. Sorry. webapp-config does provide you with some options to see what you have installed, and where you have installed it. See the man page for details. Support for hooking into 'emerge -C' should come with webapp-config v1.8, fingers crossed. Best regards, Stu Created attachment 31152 [details]
4895-squirrelmail-1.4.3_rc1-r1.log
webapp guys, can you check this out... USE=-vhosts
Why are we getting that error at the end of the emerge? I had
webapp-config-1.6 installed when the previous version was emerged. 1.7 was
emerged before this version of squirrelmail.
oh, and FWIW, it doesn't look like the old version was upgraded: (01:48:18 Tue May 11 2004 root@eradicator) /var/www/localhost/htdocs/squirrelmail $ ls -l config total 25 lrwxrwxrwx 1 root root 62 Apr 30 12:50 conf.pl -> /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs/config/conf.pl -rw-r--r-- 1 root root 16751 Apr 30 12:50 config.php -rw-r--r-- 1 root root 191 Apr 30 12:50 config_local.php lrwxrwxrwx 1 root root 64 Apr 30 12:50 index.php -> /usr/share/webapps/squirrelmail/1.4.2-r5/htdocs/config/index.php Urgh. That's an interesting error to say the least. I've managed to reproduce it locally, and am looking into it right now. Best regards, Stu Okay, webapp-config 1.8 is now available in portage. This version successfully upgrades squirrelmail locally. Best regards, Stu alright, this bug is getting closed... the webapp version is up and running and seems to be working out well... |