7860
Comment: Added some packages
|
← Revision 8 as of 2012-06-03 13:14:20 ⇥
7925
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:
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
App::cpanminus
Current Status
The packager (Alessandro Ghedini) agrees with the rename
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
The packager (Alessandro Ghedini) agrees with the rename, as noted with the discussion around cpanminus
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