Hello, I am attaching an ebuild for RT, as well as 5 ebuilds for Perl modules not found in Portage (generated by g-cpan.pl) that RT depends on. RT is an industrial-grade request tracker system ( http://www.bestpractical.com/rt/ ). This ebuild is based on two previous versions discussed at http://forums.gentoo.org/viewtopic.php?t=52692&postdays=0&postorder=asc&start=0 - This version can semi-intelligently handle upgrades from previous RT3 installations, and warns about upgrading from RT2. - Currently only Apache1/mod_perl1 is supported; support for fastcgi would be nice. - needs >=dev-lang/perl-5.8.3 and unstable Storable and dbix-searchbuilder I suggest net-www
Created attachment 33862 [details] rt-3.0.11.ebuild
Created attachment 33863 [details, diff] Makefile.in.gentoo
Created attachment 33864 [details, diff] README.gentoo
Created attachment 33865 [details, diff] config_layout.gentoo
Created attachment 33866 [details] rt_apache1.conf
Created attachment 33867 [details] Font-AFM-1.19.ebuild
Created attachment 33868 [details] HTML-Format-2.04.ebuild
Created attachment 33869 [details] Text-Autoformat-1.12.ebuild
Created attachment 33870 [details] Text-Quoted-1.7.ebuild
Created attachment 33871 [details] Text-Reform-1.11.ebuild
Makefile.in.gentoo, README.gentoo, config_layout.gentoo, and rt_apache1.conf should go into files/3.0.11
one of y'all interested?
Created attachment 33899 [details] rt-3.0.11.ebuild Fixed location of rt_apache1.conf
As requested, here's some feedback on the ebuild. And some questions too. First off, does it have to run under mod_perl? Is it possible to make it run as a cgi-bin at all? That'd allow us to run rt under Apache 2, plus the 13 or so web servers we currently have in Portage. If not, no worries. I'd really like to see this ported to use the new webapp.eclass. This should give you virtual host support, and more reliable values for HTTPD_ROOT, HTTPD_USER and HTTPD_GROUP. Btw, HTTPD_ROOT should never be /home/httpd/htdocs ;-) This isn't the simplest app to try and make work with webapp.eclass, because of the configure stage. We never designed webapp.eclass with that in mind, so you might need some help (and extra functionality) from us. I'm still working on the developer howto docs for webapp-config et al. For now, all I can suggest is that you install net-www/webapp-config v1.10-r1 (or -r2 when it appears), and read the man pages that come with it. There are example ebuilds included; you can also look at existing ebuilds in net-www that use webapp.eclass. You can't reliably set variables in pkg_setup(), and rely on them still being set when pkg_postinst() or src_install() is called. Also, you can't rely on has_version to be sure that you're definitely upgrading. There are (alas) cases where it does not work. If we're able to get this ebuild working with webapp.eclass, it can take of that for you. For adding groups, inherit eutils, and use the enewgroup function. There's nothing you can do about it, but it's worth noting that rt (like bugzilla) suffers from our poor support for database apps. No production server should ever have the root (mysql) or postgres (postgresql) users with no password. I notice that you have to supply these values at configure time. Can they be overridden in a config file? If not, then we really need to file a bug UPSTREAM to get that addressed. Hope that helps, Stu
Running RT as a CGI should be possible theoretically, but performance would be virtually nonexistent as the script has a terrible startup overhead (tons of perl modules to load). However, RT runs as a FastCGI just fine (I'm using it in production), so I'd really like to see this supported in the ebuild. Also, running several instances (in virtual hosts) doesn't work under mod_perl, only as FastCGI. Regarding DBs, I don't think the root/postgres password has to be supplied to configure; during the RT installations I did, the make stage asked for the password interactively.
I'll start working on adding FastGGI and Apache2 support (wanted to get the basics first). I'll doublecheck the db passwords issue. The webapps eclass looks very promising. It'll probably take me a little to figure it out, but stay tuned. Stuart, thanks a lot for your comments. Incidentally, could you give me an example when has_version doesn't work?
Okay, it's a bit off-topic, but you know more about perl than me, so here's a chance to pick your brains ;-) How widely supported is FastCGI for perl apps? Would it be realistic / feasible for us to try and make it the default approach for perl-based web apps? Regarding 'has_version', it breaks in this way. Because you can't rely on variables you set outside of any function in an ebuild, you have to call 'has_version' in pkg_postinst(). Unfortunately, by then, portage thinks that the current ebuild is already installed, so it always returns true :( I opened a bug sometime ago asking the Portage devs to add a $UPGRADING variable into Portage itself, but unfortunately no-one seems interested in doing anything about it. Best regards, Stu
I am definitely not enough of a Perl expert to make suggestions about default installs, but here's my 2 cents anyway. I have come across quite a few people who swear by mod_perl, and many others who prefer fastcgi, so someone is going to be unhappy either way. As far as I understand, the good thing about fastcgi is that it's not limited to Perl---you can just as easily have a Python app doing the work. A good example of that is Quixote, a web-publishing framework written in Python. It can work with Apache and mod_snake/mod_python, fastcgi and scgi (a fastcgi-like protocol written by the Quixote folks), as well as medusa and twisted with [fs]cgi. I vaguely recall reading some benchmarksposted to their mailing list showing that scgi was much faster that everything else, and as Sebastian pointed out, is much better for having several instances of the webserver. So, in a nutshell: fastcgi support is definitely a good thing, and I'll get going on it right away. As regards default installs---maybe somebody from webapps can shed some light on this. As for has_version, I actually ran into that, but mistakenly thought that variables are persistent across function calls ($UPGRADE in this ebuild worked, but I'm sure there are situations where it won't). Still, thanks for the explanation.
pcgi, scgi, fastcgi et al are all things I currently support in the tree, as I once needed them for a Zope deployment, and stuck them in. i prefer pcgi of the lot, but it's a PITA sometimes still.
From the Gentoo Ebuild Documentation: "Currently, Portage installs all build-time and run-time dependencies and leaves it at that. At a later stage, it will be possible to trim your installation so that only the run-time dependencies are left installed." Should we consider using RDEPEND instead of DEPEND since most all of the perl modules and whatnot are run-time dependencies? Ryan Roland Indiana University
it is important to distinguish between RDEPEND and DEPEND. If the perl modules are used in run-time, they are certainly RDEPENDS. This becomes particularly important when people use tbz2's to emerge... only RDEPENDS are considered when emerging from tbz2, so if they are not there, it will simply not work.
Created attachment 34588 [details] rt-3.2.0.ebuild
Created attachment 34589 [details] postinstall-en.txt post-install instructions for webapp-config
Created attachment 34590 [details] reconfig reconfigure hook for webapp
Created attachment 34591 [details] rt_apache.conf
Created attachment 34592 [details] FCGI-0.67.ebuild
Created attachment 34593 [details] HTML-Scrubber-0.08.ebuild
Created attachment 34594 [details] Module-Versions-Report-1.02.ebuild
Created attachment 34595 [details] Tree-Simple-1.05.ebuild
Ok, just uploaded a new revision of the ebuild, which has been massively reworked and improved. - RT 3.2.0 came out yesterday, so this is also a version bump. The ChangeLog is posted below - the ebuild now uses webapp.eclass and thus handles virtual hosts in a much saner way. My understanding is that webapp-config doesn't have all of its functionality yet (namely installing server config files), so for now some manual configuration is required (examples and guidance is of course provided). Big thanks to Stuart for his help with this - support for fastcgi, Apache2, and mod_perl2 has been added. I tried to figure out scgi support, but I have no idea how it works, and the "Apache and scgi" link on the RT site is helpfully 404-ed. If anyone knows how to set it up, let me know---should be a trivial addition. - RT now has its own standalone httpd, which seems to work just fine, so if all else fails, there is a fallback option. - Perl deps have been cleaned up, and a few more added (resulting in a couple extra ebuilds attached) - most of the dependencies are now RDEPEND's as RT doesn't really need anything to build - checking for upgrades is now reliable and sane thanks to webapp.eclass - database issues: DBA's password is needed during database initialization, but the database itself uses a non-priviledged user/password. This can now be configured interactively during installation, or supplied in a config file later on. That's about it. Comments/suggestions/success stories/feature requests/bug reports are most welcome---the ebuild obviously needs more testing. ---------- CHANGELOG Email handling * Preview who will receive email about new ticket updates before you send your message * You can disable notification to individual users on a per-ticket basis * RT provides a full historical view of each message RT sends including all message headers * HTML email and image attachments are now displayed inline when viewing a ticket Searching * RT now sports a brand-new search user interface, retooled to make it easier to build much more complex queries * Now you can save searches and optionally to share them with groups of your coworkers * Search results can be displayed in a per-query customizable format. * Search results are now downloadable as tab-delimited data, perfect for importing into Microsoft Excel(tm). * Search results can now be syndicated as RSS feeds * Search results can be downloaded in a simple text format, modified and re-uploaded later Web interface * The homepage has been overhauled to provide a "quick ticket creation" form and a list of the newest unowned tickets * The user interface has received a minor facelift * Every 'box' in RT can now be opened or closed on the fly Database * RT now supports single-user installations on the SQLite embedded database engine instead of a full database server Web server * RT now supports single-user installations with a stand-alone HTTP server instead of an external web server like Apache Internals * RT now provides an 'Attributes' table, which allows local developers to easily extend all of RT's database tables with new read/write attributes without needing to modify RT's core schema * Code has been refactored, cleaned up and more extensively tested throughout the system
Created attachment 34601 [details] rt-3.2.0.ebuild Commented out mod_perl2 stuff; if you really want it, just uncomment it. Apache2 now will default to fastcgi
Created attachment 34602 [details] postinstall-en.txt webapp doesn't handle backquotes (`) properly, eating some of the instructions
I'd like to give this ebuild a try, but how do I do this? Where should I put the various files, and how do I proceed then? Apologies if this seems an exceedingly stupid question, I couldn't find anything helpful in the portage docs.
Created attachment 34711 [details] rt-3.2.0.ebuild fixed libapreq dependency. if you need libapreq2, grab it from http://bugs.gentoo.org/show_bug.cgi?id=35406
Created attachment 34712 [details] reconfig minor beautification
Created attachment 34713 [details] Text-Quoted-1.7.ebuild fixed capitalization of text-autoformat
Sebastian, Take a look at http://reviewed.homelinux.org/gentoo/ebuilds/ebuilds.html.en and http://forums.gentoo.org/viewtopic.php?t=52692&postdays=0&postorder=asc&start=0 The short version mkdir -p /usr/local/portage/net-www/rt/files for a in CGI-SpeedyCGI Font-AFM HTML-Scrubber Text-Quoted Tree-Simple FCGI HTML-Format Module-Versions-Report Text-Reform; do mkdir -p /usr/local/portage/dev-perl/${a}; done then edit your /etc/make.conf and enable PORTDIR_OVERLAY: PORTDIR_OVERLAY=/usr/local/portage Place rt-3.2.0.ebuild in /usr/local/portage/net-www/rt (be sure to grab the most recent version), reconfig, rt_apache.conf and postinstall-en.txt in /usr/local/portage/net-www/rt/files , and all Perl ebuilds in their respective directories. then generate digests for all ebuilds ebuild /usr/local/portage/net-www/rt/rt-3.2.0.ebuild digest etc, and then emerge -pv rt Take a look at the USE flags that you will be using (don't do apache2 unless you know what you are doing), check what's going to be installed, verify that everything is as you want, and then emerge -v rt The ebuild will walk you through stage 2 of the installation. Feel free to email if you have more questions.
Created attachment 36771 [details] rt-3.2.1.ebuild Ok, let's face it---my first 2 ebuilds were braindead. I'm attaching a much cleaner version that I am no longer embarassed about. Comments/suggestions welcome.
Created attachment 36772 [details] files/postinstall-en.txt
Created attachment 36773 [details] files/reconfig
Created attachment 36815 [details] files/postinstall-en.txt small bug
Perl Module comments: Remove hardcoded references to the package name in the src_uri. For instance SRC_URI="http://www.cpan.org/modules/by-authors/id/G/GA/GAAS/Font-AFM-1.19.tar.gz" should be SRC_URI="http://www.cpan.org/modules/by-authors/id/G/GA/GAAS/${P}.tar.gz" Text-Autoformat: In tree already, text-autoformat In addition, a lot of these are missing DESCRIPTIONS even though they do have them (a few pulled as I noticed them)... HTML-Element: DESCRIPTION="Class for objects that represent HTML elements" (from the module itself - perldoc ;) ) Module-Versions-Report: DESCRIPTION="report versions of all modules in memory" Tree-Simple: DESCRIPTION="A simple tree object" Text-Quoted: DESCRIPTION="Extract the structure of a quoted mail message" Which version of WWW::Mechanize did you confirm this with? There were differences between versions that may not may affect your package. Finally, I'm not favoring the automatic inclusion and unmasking for all arch's that I see in these perl ebuilds. New perl modules should only receive KEYWORDS for arch's you an test on, and should be ~arch'd until we can validate no new bugs.
Final question - why is this pegged with at least perl 5.8.3? 5.8.4 is stable, and I haven't seen anything to indicate it won't work on 5.8.2
The README for 3.2.0 (the most recent tarball I have around) says: o Perl 5.8.3 or later (http://www.perl.com). Perl versions prior to 5.8.3 contain bugs that could result in data corruption. We recommend strongly that you use 5.8.3 or newer. RT may function with perl 5.8.0 and later, but is unsupported in that configuration. The README also recommends at least MySQL-4.0.13; the current ebuild only requires MySQL-4.0.9 or newer, but this should not be a practical issue.
I'll be committing RT in the next few days, and will check all the deps again then.
In CVS, please test and report bugs.
There are some dependency problems when USE=apache2: rt-3.2.1 requires >=dev-perl/HTML-Mason-1.23, dev-perl/HTML-Mason-1.25 requires >=dev-perl/libapreq-1.0-r2, and dev-perl/libapreq-1.2-r1 requires <dev-perl/mod_perl-1.99, which leads to dev-perl/mod_perl-1.27-r4 and of course net-www/apache-1.3.31-r3. My relevant USE flags are: +apache2 -fastcgi +mysql -postgres +vhosts Bug #35406 may be relevant to this. Renat should be familiar with this one; I suspect he has a masked or local libapreq-2 installed, but that's just a guess.
To quote the ebuild: if use apache2; then ewarn "mod_perl2 isn't ready for prime time, fastcgi will be used instead" ewarn "If you really want mod_perl2, you can edit the ebuild and uncomment a few lines" ewarn "but if your RT breaks, you get to keep the pieces." ewarn fi Andy, the pieces are all yours. :) You can manually install libapreq2 from the bug you referenced, but upstream doesn't recommend Apache2+mod_perl2 yet, so I won't be adding support for it to the ebuild until mod_perl2 is deemed stable. Feel free to place your bets as to when that will happen.
I did not want or request mod_perl, or edit the ebuild. The ebuild is supposed to use FCGI for apache2, which it does try to merge, but it also tries to merge apache-1.3 and mod_perl for apache-1.3. mod_perl results from the libapreq dependency. I never actually let the merge start, once I saw the dependencies. Calculating dependencies ...done! [ebuild N ] dev-perl/Scalar-List-Utils-1.11 14 kB [ebuild N ] dev-perl/Class-Data-Inheritable-0.02 3 kB [ebuild N ] dev-perl/Devel-StackTrace-1.03 6 kB [ebuild N ] dev-perl/Exception-Class-1.14-r1 12 kB [ebuild N ] dev-libs/mm-1.2.1 211 kB [ebuild N ] net-www/apache-1.3.31-r3 +pam 3,146 kB [ebuild N ] dev-perl/mod_perl-1.27-r4 -ipv6 363 kB [ebuild N ] dev-perl/Apache-Test-1.07 94 kB [ebuild N ] dev-perl/libapreq-1.2-r1 271 kB [ebuild N ] dev-perl/Attribute-Handlers-0.78-r1 15 kB [ebuild N ] dev-perl/Params-Validate-0.72 47 kB [ebuild N ] dev-perl/Class-Container-0.10 17 kB [ebuild N ] dev-perl/Digest-SHA1-2.07 37 kB [ebuild N ] dev-perl/IPC-ShareLite-0.09 35 kB [ebuild N ] dev-perl/Error-0.15-r2 7 kB [ebuild N ] dev-perl/Cache-Cache-1.02 32 kB [ebuild N ] dev-perl/HTML-Mason-1.25 321 kB [ebuild N ] dev-perl/Compress-Zlib-1.22 35 kB [ebuild N ] dev-perl/IO-Zlib-1.01 4 kB [ebuild N ] dev-perl/Archive-Tar-1.09 26 kB [ebuild N ] dev-perl/module-info-0.20 39 kB [ebuild N ] dev-perl/yaml-0.35 54 kB [ebuild N ] dev-perl/module-build-0.19 72 kB [ebuild N ] dev-perl/log-dispatch-2.08 26 kB [ebuild N ] dev-perl/text-wrapper-1.000 5 kB [ebuild N ] dev-perl/locale-maketext-fuzzy-0.02 6 kB [ebuild N ] dev-perl/text-reform-1.11 20 kB [ebuild N ] dev-perl/text-autoformat-1.12 16 kB [ebuild N ] dev-perl/Text-Quoted-1.7 16 kB [ebuild N ] dev-perl/FCGI-0.67 84 kB [ebuild N ] dev-perl/HTML-Scrubber-0.08 16 kB [ebuild N ] dev-perl/Font-AFM-1.19 8 kB [ebuild N ] dev-perl/regexp-common-2.113 132 kB [ebuild N ] dev-perl/TermReadKey-2.21 34 kB [ebuild N ] dev-perl/HTML-Tree-3.17 115 kB [ebuild N ] dev-perl/Test-Manifest-0.92 3 kB [ebuild N ] dev-perl/XML-RSS-1.02 37 kB [ebuild N ] dev-perl/HTML-Format-2.04 22 kB [ebuild N ] dev-perl/Test-Builder-Tester-0.09 8 kB [ebuild N ] dev-perl/Sub-Uplevel-0.08 16 kB [ebuild N ] dev-perl/Test-Exception-0.15 7 kB [ebuild N ] dev-perl/Tree-Simple-1.05 20 kB [ebuild N ] dev-perl/text-template-1.44 42 kB [ebuild N ] dev-perl/WWW-Mechanize-1.0301 84 kB [ebuild N ] dev-perl/Module-Versions-Report-1.02 4 kB [ebuild N ] dev-perl/i18n-langtags-0.28 21 kB [ebuild N ] dev-perl/locale-maketext-1.06 43 kB [ebuild N ] dev-perl/locale-maketext-lexicon-0.32 23 kB [ebuild N ] dev-perl/FreezeThaw-0.43-r1 10 kB [ebuild N ] dev-perl/Apache-Session-1.54 26 kB [ebuild N ] dev-perl/Apache-DBI-0.92 26 kB [ebuild N ] dev-perl/Memoize-1.01 46 kB [ebuild N ] dev-perl/Test-Inline-0.15-r1 13 kB [ebuild N ] dev-perl/class-returnvalue-0.51 4 kB [ebuild N ] dev-perl/MLDBM-2.01 9 kB [ebuild N ] net-www/mod_fastcgi-2.4.2 +apache2 95 kB [ebuild N ] dev-perl/Time-modules-2003.0211 21 kB [ebuild N ] dev-perl/Want-0.07 14 kB [ebuild N ] dev-perl/dbix-searchbuilder-1.01 37 kB [ebuild N ] www-apps/rt-3.2.1 +apache2 -fastcgi +mysql -postgres +vhosts 1,173 kB I used emerge --debug to find the libapreq -> mod_perl dependency. I don't have USE=fastcgi, but that doesn't matter with USE=apache2: you get it in any event, and turning it on doesn't seem to change build options. Dependencies for libapreq are: DEPEND=">=sys-apps/sed-4 dev-perl/Apache-Test <dev-perl/mod_perl-1.99" Maybe they should be: DEPEND=">=sys-apps/sed-4 dev-perl/Apache-Test !apache2? ( <dev-perl/mod_perl-1.99 )" HTML-Mason is pulling in the libapreq dependency. I really have no idea if libapreq really won't work without mod_perl, or if HTML-Mason always needs libapreq. But as it stands, if you want to run rt with apache2, it will still always try to merge apache1, even if you do have USE=fastcgi.
Oh, this makes much more sense now. Thank you for explaining what's going on (you are right, I do have libapreq2 installed after working on #35406). Here's what I found after a brief investigation. RT needs HTML-Mason, which currently DEPENDS on >=dev-perl/libapreq-1.0-r2. The latest libapreq in the tree is 1.3 (although libapreq2 is in Bugzilla), which correctly depends on <dev-perl/mod_perl-1.99, while libapreq2 depends on >=dev-perl/mod_perl-1.99. mod_perl-1.23 pulls in Apache1. Now, HTML-Mason apparently works fine with Apache2/mod_perl2. The culprit is libapreq, or the absence of libapreq2 in the tree. I have filed bug #61893, please file your comments there. For now, I see no other way to fix the issue other than remove IUSE="apache2", so for now RT will always need apache-1*. I'm open to suggestions if you feel there is a better way to solve the problem. A workaround for the time being is to manually install libapreq2 and mod_perl-1.99, which should satisfy RT's deps and no longer pull in Apache 1.
