[request-tracker-maintainers] packaging of RT extensions

[Dominic Hargreaves]

On Wed, Aug 28, 2013 at 10:33:27PM +0200, Kai Storbeck wrote:
> I already wrote up some patches in June, but didn't publish it anywhere.
> I've just pushed it to my github repo [1]. I made 2 branches:
>  * honour-destdir-variable
>  * support-vendorlib
> 
> As I stated earlier, the first (honour-destdir-variable) is already
> filed upstream [2].

Yep, that looks sane. Of course from a Debian packaging point of view
it'd be much better if the thing never got bundled in inc/, too.

> Its the second patch I'd definately like to get some input on:
> support-vendorlib.
> 
> I came to my solution by looking at the contents of RT::Generated from
> an installed version of request-tracker4. This currenlty includes a
> variable already pointing to where the current packaged extensions
> install their libs into:
> 
> >   $PluginPath = '/usr/share/request-tracker4/plugins';
> 
> I suppose LocalPluginPath is for manual installs of plugins? Then where
> was PluginPath meant for?

For what we're using it for; it was added at our request:

22e95676e0467cd0f0b48a98f362d41b9723b9c9

commit 22e95676e0467cd0f0b48a98f362d41b9723b9c9
Author: Jesse Vincent <jesse at bestpractical.com>
Date:   Wed Oct 21 11:03:08 2009 -0400

    Add a systemwide plugin directory at the request of the Debian RT maintainers

> Anyway, using this patch, the arguments given by dh_auto_configure will
> now be used and stuff will be moved into the correct location.

This looks very promising. The only complication is where we have
packages that are designed to build multiple binary packages for 
multiple major releases of RT, but that can be fixed by running as much
of the build as necessary multiple times (and we don't actually have
multiple supported versions of RT at the moment and I'm hoping to keep
RT 4.2 in request-tracker4).

Have you proven this patch by modifying a currently-packaged extension
to use it? I guess that would be the next step if not.

> What is missing is doing something useful with other valid values of
> INSTALLDIRS [3]. Valid settings are perl, site and vendor. I could let
> 'site' install to RT::LocalPluginPath, which is more or less the current
> behaviour if one doesn't supply an INSTALLDIRS argument.

Sounds reasonable.

Cheers,
Dominic.