[request-tracker-maintainers] RT command-by-mail

Matthew Johnson debian at matthew.ath.cx
Thu Mar 22 10:51:31 UTC 2007


On Wed, Mar 21, 2007 at 09:57:11PM +0200, Niko Tyni wrote:
 
> I had a look at the packaging, some thoughts:
> 
> - the standard naming would be librt-extension-commandbymail-perl. 

not librt3.6-...? I was looking at the rt3.6-client and so on packages
for naming.

> - I think it would be better to install this to /usr/share/perl5 just
>   like any other perl module instead of /usr/share/request-tracker3.6
>   (INSTALLDIRS=vendor etc., see the Debian Perl policy)

Will that work? I'm not hugely au fait with how perl deals with this. I
assumed it would need to be installed in the RT directory (which is
where it installs itself)

> - the module is not specific to RT 3.6; it looks like 3.4.6 should work 
>   too (and for 3.6 it needs > 3.6.1 anyway, see the patch directory)

Looked like it needs to patch the RT tree for 3.4 versions. This is
presumably not something which can be done with a deb.

> - the debian/RT.pm trick is nice, but is it really needed? It looks
>   like all the fuss is just for t/utils.pl, and the tests look invasive
>   enough that there's no sense running the at build time anyway...

The perl 'configure' script needs it or it needs RT to be already
installed to use that one. I wasn't originally sure that I could just
use the installed RT one and wouldn't need to put in different
paths. It's quite nice not to build-dep on RT anyway.

> - the dependencies on libmime-perl should be versioned (>= 5.420)

Thanks

> - ${perl:Depends} and dh_perl would be good too

I couldn't get dh_perl to do anything. dh_perl or dh_perl and the paths
to the modules didn't produce anything in the depends line.

> - there's 'Makefile.old' in .diff.gz , that's just cruft

Oops, that'll go away when I rebuild the deb.

> - please don't repackage the original tarball

I didn't intend to, but I only found the unpackaged source on
search.cpan site, and not a tarball. So I downloaded it and tarballed it
up.

> - using '-$(MAKE) clean' is suboptimal; see #325372

Hmm, that's what dh_make produced. The arguments in that bug report are
reasonable, although I do wonder if any bugs have arisen from this
particular ignoring of errors.

 
> The important thing is to run the database schema upgrades, I don't
> think there are any other big issues.
> 
Thanks

Matt
--
Matthew Johnson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-request-tracker-maintainers/attachments/20070322/2fccff4c/attachment.pgp


More information about the pkg-request-tracker-maintainers mailing list