Applications

This page is for coordinating details regarding the long-term maintenance of applications as part of the Debian Perl Group.

Conventions in this document:

Issues

Regarding the ITP for libapp-cpanminus-perl (to package the application better known as cpanminus, or cpanm), Christine Spang said:

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.

Proposal

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 a single binary package: libsql-translator-perl

  3. Set up the libsql-translator-perl package so that it Provides sqlfairy

Some consideration is required when there are reverse dependencies on the application component of a package, especially when version considerations are required, since a virtual package (via Provides) will not allow for a version dependency to be specified. In this case, we can opt instead to:

  1. A source package called libsql-translator-perl

  2. Produce two binary packages: libsql-translator-perl and sqlfairy

Where possible, we should also contact maintainers of, or file bugs against, the reverse dependency packages to instruct them to use the appropriate library name moving forward. It is unlikely we will need to do this, since most Perl packages depending on other Perl packages will simply use the exposed Perl interface, rather than calling external Perl applications.

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.

Precedent and Future Plans

We already maintain multiple Perl applications within the Debian Perl Group:

SQL::Translator

Current Status

Remediation Plan