Applications in the Perl Group

[Jonathan Yu <jawnsy@cpan.org>]

Hi all,

First off, I don't object to the presence of applications being
packaged and released under the Debian Perl Group. Not everything we
package and maintain matches lib.*-perl, and rightly so.

We maintain some applications like SQLFairy (sqlfairy +
libsql-translator-perl), which have both a reusable library component,
as well as a command-line application component.

A month ago, libapp-cpanminus-perl was uploaded to the archive (it
currently sits in NEW) as a resolution to an ITP (BTS#579147) -- see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579147

However, as noted in message 15 of that bug, Christine Spang
originally had an objection to the naming:

> I'd also like to request that the package be called
> 'cpanminus' rather than 'libapp-cpanminus-perl'. While this
> is the default naming scheme for software from CPAN, it is
> not required and makes no sense for the App::
> namespace---these are meant to be standalone applications,
> and having their package names start with 'lib' is confusing
> and ugly.

I *very much* agree with this, and don't know how it slipped by in the
first place.

As David Bremner noted on the IRC channel, it's not a big deal to ask
ftp-master to reject the package, as it is currently sitting in NEW.
However, the real purpose for this message is to establish a policy
for the future.

In the case of SQL Fairy:

1. A source package exists called 'sqlfairy'
2. Two binary packages are produced: sqlfairy (which includes the
application parts) and libsql-translator-perl.

I understand  #1 is probably the result of historical reasons. But
moving forward, here is what I would propose.

Where a reusable module exists, that provides a command-line
application (e.g. SQL::Translator/SQLFairy), we should have:
1. A source package called libsql-translator-perl
2. Produce two binary packages: sqlfairy and libsql-translator-perl

Where an application exists (e.g. in the App::acme namespace), we should have:
1. A source package called acme
2. Produce a binary package called acme
3. If there is later some reusable component taken out of the original
app, and distributed with the App package (e.g. other libraries now
depend on this package), then we should also produce a
libreusable-component-perl package.

I believe the latter scenario is what actually happened with sqlfairy,
and I guess nobody sees it worthwhile to bother getting the source
package renamed.

When I have some time, I would also like to put together an action
plan detailing the current packages that have these issues (e.g.
lib.*-perl packages that are also installing things in bin/). Of
course, if anyone else might be interested in this, all the better :-)

Cheers,

Jonathan