This should help resolve a number of open bugs. 53057 nor P2 x86 web-apps@gentoo.org NEW twiki 20030201 ebuild has wrong dependencies 60460 nor P2 All web-apps@gentoo.org NEW www-apps/twiki needs testing w/ PHP 5 76782 tri P3 All web-apps@gentoo.org NEW web-apps/twiki is GPL The dependencies should be correct now, testing with PHP 5 is incorrect, TWiki uses perl, and this ebuild lists TWiki as GPL. This also might address bug 52157, as I used the last attachment there as a template for this ebuild (I changed very little). Reproducible: Always Steps to Reproduce:
Created attachment 48077 [details] twiki-20040902-r1.ebuild
Comment on attachment 48077 [details] twiki-20040902-r1.ebuild Fixed License to GPL, dependencies, etc
Instead of mail-mta/sendmail, could also use dev-perl/libnet since TWiki supports mailing via Net::SMTP provided by libnet
I'd like to recommend that twiki be removed from portage. It is just so useless to me and I can't see how it is useful to anyone else. Reasons given below: 1. This ebuild installs to /var/www/twiki. I put mine in /var/www/hostname/htdocs/twiki so I have to move it. When I upgrade a new twiki ebuild, it will go to /var/www/twiki again. 2. The current ebuild is far from perfect. The 97_twiki.conf file is not 100% correct. Permissions are not all set correctly according to the installation guide. 3. There is so much hands-on tweaking which goes on with twiki, that I have never found ebuilds or debian packages useful for this package. I've always used (or I should say reverted) the tarball on the twiki.org site. When I upgrade, I install a new version in a new directory, and port the data over manually, and set permissions manually. Would a twiki install even work if you clobbered /var/www/twiki directory with a new tarball? Probably not, since many things in the Main web such as TWikiUsers and TWikiPreferences would be clobbered AFAIK. 4. We suggest at the end of the ebuild installation that the user review the install documentation online. Why? Because clearly the ebuild does nothing but extract a tarball and some more steps are needed. So why have the ebuild at all? 5. Makes no sense to have an automated ebuild for a program which is basically a non-static-data distribution with a few scripts. Please correct me on anything which you think I am wrong about.
Although all of these arguments are true, I don't think that warrants removing the package from portage. The package is very flawed, however, I beleive the point of the package should be to perform the necessary steps in the installation guide. I find the installation steps to be more than annoying as I have never used TWiki before. It takes me a long time to follow them, and the necessary steps seem to be somewhat scattered around different TWiki topics. The benefit of making a TWiki package is that once it is written correctly, installing should be easy, and it should support the web-apps or web-config system. This should allow setting up TWiki with virtual hosts and apache very easy. I'm not saying the current ebuild is even moderately where it should be, but I believe there is a point to having an ebuild. If a user doesn't want to use it, so be it, but does that justify removing it completely?
Created attachment 48368 [details] twiki-20040902-r1.ebuild Updated version should work correctly (not report any errors).
Created attachment 48369 [details, diff] twiki-20040902-gentoo.patch This is a patch for the TWiki source. It currently only fixes the bin/setlib.cfg file.
Created attachment 48370 [details] twiki-20040902-twiki.conf Updated twiki.conf that contains the correct directory for apache
Created attachment 48371 [details, diff] twiki-20040902-gentoo.patch Fixed location (had an extra /twiki)
twiki-20041030 has been committed. Old and very broken versions have been cleaned out. The web-apps team would like to apologize for the loss of functionality you may have experienced.
