RT supports a common extension format for adding functionality to extensions, and it is obviously useful to package some of them in Debian.
Most RT extensions use Module::Install:RTx upstream. Because this needs modifications to be useful for Debian, and because embedded in the extensions themselves (in inc/) things can be a bit messy. In addition there is not really a good infrastructure for managing database schema/content modifications during extension module installation at the moment.
This wiki page is an attempt to collect together common/best practices for extension maintenance, and coordinate activity on common tools/patches.
There is a packaged version of the normally-embedded Module::Install::RTx maintained by KURASHIKI Satoru (libmodule-install-rtx-perl).
First, an audit of existing modules in sid:
(Link to all team git repos: http://anonscm.debian.org/cgit/pkg-request-tracker)
Source name |
Description |
Team maintained? |
Primary maintainer |
Notes |
External authentication |
No |
Tom Jampen |
A separate packaging effort http://anonscm.debian.org/cgit/pkg-request-tracker/rt-extension-authen-externalauth.git/ should probably be tidied up |
|
Asset tracking |
Yes |
Dominic Hargreaves |
Not yet uploaded |
|
Asset tracking |
Yes |
Bradley Bell |
Abandoned upstream, should be removed |
|
Calendar view for Request Tracker 4 |
No |
KURASHIKI Satoru |
- |
|
edit ticket's custom fields on reply/comment |
No |
KURASHIKI Satoru |
- |
|
Gantt charts |
No |
KURASHIKI Satoru |
- |
|
Repeat tickets based on schedule |
No |
Joost van Baal-Ilić |
- |
|
quickly spawn linked tickets in different queues |
No |
KURASHIKI Satoru |
- |
A note on package naming: RT extension source packages are generally named 'rt-extension-foo' but the binary packages are named 'rt4-extension-foo'. This is to allow for the possibility of a major new RT version which we want to allow to be co-installed.
The ultimate aim should be that the three-line dh style rules file or something close will work for all RT extensions. At the moment there are several customisations:
- Setting RTHOME to /usr/share/request-tracker4 (or multiple directories, where extensions have allowed for building multiple versions)
- Patching M::I::RTx to use PREFIX/DESTDIR (patched in slightly different ways by different modules
rt-authen-externalauth: https://sources.debian.net/src/rt-authen-externalauth/0.25-1/debian/patches/01-fix-plugindir.patch
rt-extension-assettracker: http://anonscm.debian.org/cgit/pkg-request-tracker/rt-extension-assettracker.git/tree/debian/patches/0001-Make-RTx-honour-the-DESTDIR-xxx-variable.patch
rt-extension-assets: http://anonscm.debian.org/cgit/pkg-request-tracker/rt-extension-assets.git/tree/debian/patches/module_install_rtx_destdir.patch,
- rt-extension-calendar: no patches, specific PREFIX manually in rules
Patch submitted upstream and included in upcoming libmodule-install-rtx-perl package: https://github.com/bestpractical/module-install-rtx/pull/1
- Patching M::I::RTx to use INSTALLDIRS (only needed for some modules):
rt-extension-assets: http://anonscm.debian.org/cgit/pkg-request-tracker/rt-extension-assets.git/tree/debian/patches/module_install_rtx_installdirs.patch
Patch submitted upstream and includied in upcoming libmodule-install-rtx-perl package: https://github.com/bestpractical/module-install-rtx/pull/3
- Iterating over a list of RT major releases to support. At the moment only '4' is a supported major release, so this is not strictly required. Dom somewhat prefers to keep things simple when that's possible.
- Moving inc/ out of the way to prefer Debian packaged M::I
- rt-extension-jsgantt only - as an alternative to patching M::I::RTx in place (although missing a build-dep on libmodule-install-rtx-perl?)
- Various custom database maintenance scripts, to be documented (note: many extensions don't need any schema or content modifications so this only applies to a few)
Testing
Out of the box, RT extension packages' test suites can't be run in an isolated fashion since they need an installed version of RT with a writable database in place. Packages probably shouldn't even attempt it, in case the user happens to build the package in an environment where they have write access to a production database.
I wrote a mailing list post about this a few weeks ago with some possible solutions, but am still hoping for feedback:
Database manipulation
TODO: document current status (example: rt-extension-assettracker and rtfm); need for reusable tools