Bugzilla Bug 77308

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 an attachment (id=48077) [edit]
Fixed License to GPL, dependencies, etc

(From update of attachment 48077 [edit])
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 an attachment (id=48368) [edit]
twiki-20040902-r1.ebuild

Updated version should work correctly (not report any errors).

Created an attachment (id=48369) [edit]
twiki-20040902-gentoo.patch

This is a patch for the TWiki source.  It currently only fixes the
bin/setlib.cfg file.

Created an attachment (id=48370) [edit]
twiki-20040902-twiki.conf

Updated twiki.conf that contains the correct directory for apache

Created an attachment (id=48371) [edit]
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.