Differences between revisions 1 and 2
Revision 1 as of 2010-05-05 21:05:33
Size: 105
Editor: JonathanYu
Comment:
Revision 2 as of 2010-05-06 15:05:41
Size: 2608
Editor: JonathanYu
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
These are a list of things Debian needs in order to package your Perl distributions quickly and easily. These are a list of things Debian needs in order to package your Perl distributions quickly and easily. I'm not sure whether this should be considered more of a wishlist or a checklist, but these are the things that most commonly stall us from integrating modules.

 1. Provide adequate copyright/license information
    * By far the most common thing holding back many modules
    * Provide complete copyright and license details, covering all files
    * Specify things like:
      * 1999-2002, Some Author <some@example.com>
      * This library is free software and may be distributed under the same terms as perl itself.
    * If copyright holders have not been historically known, or many people worked on a package, it's best to consider each author a copyright holder (per the Berne Convention)
      * Matt S. Trout has a script called copyrite-gen that helps with this
      * More copyright holders = more work for Debian, as things are tracked individually
      * A COPYRIGHT.yml or something as part of META.yml for copyright information would be nice, so we can autogenerate copyright information
        * A metadata file that can be used to generate copyright clauses for POD would be nice, rather than vice-versa
        * Maybe a specific POD format can be used for this, but POD is sort of painful to parse
    * For new projects or where there are few copyright holders, try to assign copyright either to a company or to a few key individuals, so that future decisions can be made (ie, in case people wish to relicense the software, or make other such decisions that require copyright holders to acquiesce)
 2. Provide some indication of whether dependencies are
    * Fully required: stuff will break without this (usually in requires in META.yml)
    * Recommended: most users will want this installed along with the software, but it's not strictly needed (nothing will break without it, including tests; modules like Test::Without::Module may be beneficial here)
    * Optional: some users may choose to use these, but a user installing the software wouldn't necessarily expect this to be installed alongside it. In Debian we call this "Suggests"
    * The key here is to make sure you don't specify things are required that are actually recommendations, or optional.
 3. Use a standard toolchain; good choices are:
    * ExtUtils::MakeMaker
    * Module::Install
    * Module::Build
    * Dist::Zilla
    These modules have all been built with Debian, and we have worked with maintainers of those systems to ensure things build nicely in Debian using them.

These are a list of things Debian needs in order to package your Perl distributions quickly and easily. I'm not sure whether this should be considered more of a wishlist or a checklist, but these are the things that most commonly stall us from integrating modules.

  1. Provide adequate copyright/license information
    • By far the most common thing holding back many modules
    • Provide complete copyright and license details, covering all files
    • Specify things like:
      • 1999-2002, Some Author <some@example.com>

      • This library is free software and may be distributed under the same terms as perl itself.
    • If copyright holders have not been historically known, or many people worked on a package, it's best to consider each author a copyright holder (per the Berne Convention)
      • Matt S. Trout has a script called copyrite-gen that helps with this
      • More copyright holders = more work for Debian, as things are tracked individually
      • A COPYRIGHT.yml or something as part of META.yml for copyright information would be nice, so we can autogenerate copyright information
        • A metadata file that can be used to generate copyright clauses for POD would be nice, rather than vice-versa
        • Maybe a specific POD format can be used for this, but POD is sort of painful to parse
    • For new projects or where there are few copyright holders, try to assign copyright either to a company or to a few key individuals, so that future decisions can be made (ie, in case people wish to relicense the software, or make other such decisions that require copyright holders to acquiesce)
  2. Provide some indication of whether dependencies are
    • Fully required: stuff will break without this (usually in requires in META.yml)
    • Recommended: most users will want this installed along with the software, but it's not strictly needed (nothing will break without it, including tests; modules like Test::Without::Module may be beneficial here)
    • Optional: some users may choose to use these, but a user installing the software wouldn't necessarily expect this to be installed alongside it. In Debian we call this "Suggests"
    • The key here is to make sure you don't specify things are required that are actually recommendations, or optional.
  3. Use a standard toolchain; good choices are:
    • ?ExtUtils::?MakeMaker

    • Module::Install
    • Module::Build
    • Dist::Zilla These modules have all been built with Debian, and we have worked with maintainers of those systems to ensure things build nicely in Debian using them.