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

[Niko Tyni]

On Thu, Mar 22, 2007 at 09:51:31AM +0000, Matthew Johnson 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 guess this goes along with the question of where to install the modules
(/usr/share/perl5 vs. /usr/share/request-tracker3.6). See below.

> > - 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 /usr/share/request-tracker3.{4,6} directories need to be kept
apart for co-installability, since the modules share the same namespace
(RT::*). That's not a problem here: there are not separate versions of
the module for 3.4 and 3.6 with the same name.

I don't see any reason why it shouldn't work in the standard place,
/usr/share/perl5, and that way 3.4 and 3.6 would share it when needed.

This also means it should go in line with the Debian Perl Policy,
including the package name.

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

I had a look, and I think it should work with an unpatched 3.4.6.
The problematic module, RT::Interface::Email, is identical in 3.6.1
and 3.4.6.

The only problem is that an 'In-Reply-To' field won't be inserted
on 3.4.6 or 3.6.1 (patch/errors_in_reply_to-RT-3.6.1.patch).
This is only fixed in 3.6.2, but I don't think it's very serious.

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

Sure, skipping a build-dependency on RT is a good thing, and
yours is quite a good way of doing this. I didn't catch the code in
inc/Module/Install/RTx.pm, which indeed makes configuring the package
very difficult without an RT.pm. Sorry for not looking at this properly.

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

That could be because you're installing into debian/tmp while
dh_perl looks in debian/<package> instead on compatibility
levels > 1. I usually just install straight into debian/<package> 
with something like

 $(MAKE) DESTDIR=$(CURDIR)/debian/rt3.6-commandbymail install

so there's no need for dh_install at all.
 
> 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.

There's a download link on the CPAN package page:

 http://search.cpan.org/~jesse/RT-Extension-CommandByMail-0.05/

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

Sure, it's mostly just a matter of style.

BTW, there's dh-make-perl too, just in case you didn't know.

Thanks for your work on this,
-- 
Niko Tyni   ntyni at iki.fi