[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