[request-tracker-maintainers] packaging of RT extensions

[Kai Storbeck]

Hey,

On 15/09/13 01:46, Dominic Hargreaves wrote:
> 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.

Ahem. Yes. Have you ever read the BEGIN block in inc/Module/Install.pm?
It tries its best shot at loading the libs in ./inc anyway, even if it
might've found a newer version installed globally. Do I understand that
correctly?

>> 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

Great!

>> 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.

I have recently rebuilt rt-extension-jsgantt in jessie. That worked
reasonably well using a stripped version of debian/rules. I pasted it on
refheap: [1], and the diff against the current version: [2].

I did have to fix a few things, instructing makemaker about VENDOR man
locations.

Man pages go into /usr/share/man, _always_ right? Do you know why
rt-extension-jsgantt's debian/rules is moving it to /usr/share/man/auto?

The latest diff for Module::Install::RTx compared to upstream's 0.31
version is now at [3].

>> 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.

I'm a bit uncertain if this work is needed. I would need to add a test
to the

> elsif ($RT::LocalPluginPath)

That code currently does what 'site' would do, and this code would only
_not_ execute when installing against an RT that doesn't have
LocalPluginPath.

Perhaps you would have some idea on how to refactor this?


Regards,
Kai

[1] https://www.refheap.com/22412
[2] https://www.refheap.com/22413
[3]
https://github.com/giganteous/module-install-rtx/compare/bestpractical:master...support-vendorlib

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-request-tracker-maintainers/attachments/20140103/13bbcd28/attachment.sig>