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:
To ensure effective communication, binary package names are specified in bold, whereas source package names a re specified in bold italics (the package name is not formatted when it unambiguously refers to either the source or binary package)
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:
A source package called libsql-translator-perl
Produce a single binary package: libsql-translator-perl
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:
A source package called libsql-translator-perl
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:
A source package called acme
Produce a binary package called acme
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
- Commonly used as a support library (e.g. for the DBIx::Class project)
Current Status
A source package exists called sqlfairy
- Two binary packages are produced:
sqlfairy (which includes the application parts)
libsql-translator-perl (which includes the libraries used by DBIx::Class)
- Note: libdbix-class-perl requires SQL::Translator, but not necessarily the applications bundled with sqlfairy (e.g. while libsql-translator-perl might Suggest or Recommend sqlfairy, it is not a Depends)
Remediation Plan
The source package will be renamed to libsql-translator-perl (from sqlfairy)
The binary sqlfairy package will be withdrawn
The binary libsql-translator-perl package will Provide sqlfairy