Differences between revisions 7 and 8
Revision 7 as of 2011-02-14 14:14:03
Size: 7860
Editor: ?AlessandroGhedini
Comment: Added some packages
Revision 8 as of 2012-06-03 13:14:20
Size: 7925
Editor: ?GregorHerrmann
Comment: put under Teams/ namespace
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from DebianPerlGroup/OpenTasks/Applications

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:

  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

  • 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

App::cpanminus

Current Status

Remediation Plan

  • We will request the removal of libapp-cpanminus-perl from the NEW area (and prevent the package from entering the archive)

    • This package has now been removed from NEW.
  • The source package will be renamed to cpanminus

  • The binary libapp-cpanminus-perl package will be renamed to cpanminus

  • There are no reusable components bundled, so no further action is required

App::perlbrew

Current Status

Remediation Plan

  • We will request the removal of libapp-perlbrew-perl from the NEW area (and prevent the package from entering the archive)

    • This package has now been removed from NEW.
  • The source package will be renamed to perlbrew

  • The binary libapp-perlbrew-perl package will be renamed to perlbrew

  • There are no reusable components bundled, so no further action is required

Twiggy

Current Status

  • This package suffers the same problems as two mentioned above (perlbrew & cpanminus)

Remediation Plan

  • We will request the removal of libtwiggy-perl from the NEW area (and prevent the package from entering the archive)

    • This package has now been removed from NEW.
  • The source package will be renamed to twiggy

  • The binary libtwiggy-perl package will be renamed to twiggy

  • There are no reusable components bundled, so no further action is required

Starman

Current Status

  • This package suffers the same problems as two mentioned above (perlbrew & cpanminus)

Remediation Plan

  • We will request the removal of libstarman-perl from the NEW area (and prevent the package from entering the archive))

    • This package has now been removed from NEW.
  • The source package will be renamed to starman

  • The binary libstarman-perl package will be renamed to starman

  • There are no reusable components bundled, so no further action is required

CPAN::Inject

Current Status

  • libcpan-inject-perl also supplies a cpaninject command-line program

Remediation Plan

  • The binary package will now Provide cpaninject (maybe cpan-inject?) as well

Dist::Zilla

Current Status

  • libdist-zilla-perl also supplies a dzil command-line application

  • It could be argued Dist::Zilla is primarily an application (and not meant to be used as a library)

Remediation Plan

There are two options:

  • Option 1
    • Set libdist-zilla-perl to Provide distzilla as well

  • Option 2
    • Rename source package to distzilla

    • Rename binary package to distzilla

    • Optionally Provide libdist-zilla-perl if its library stuff is re-used at a later date

Module::Starter

Current Status

  • libmodule-starter-perl also supplies a module-starter command-line application

  • It could be argued Module::Starter is primarily an application (and not meant to be used as a library, similarly to Dist::Zilla)

Remediation Plan

There are two options:

  • Option 1
    • Set libmodule-starter-perl to Provide module-starter as well

  • Option 2
    • Rename source package to module-starter

    • Rename binary package to module-starter

    • Provides libmodule-starter-perl at least until every package that depends on it will be updated to use the new name

Dancer

Current Status

  • libdancer-perl also supplies a dancer command-line program

Remediation Plan

  • The binary package will now Provides dancer as well

Plack

Current Status

  • libplack-perl also supplies a plackup command-line program

Remediation Plan

  • The binary package will now Provides plackup as well