r69969 - /website/policy.pod

jawnsy-guest at users.alioth.debian.org jawnsy-guest at users.alioth.debian.org
Sun Feb 27 18:27:13 UTC 2011


Author: jawnsy-guest
Date: Sun Feb 27 18:26:54 2011
New Revision: 69969

URL: http://svn.debian.org/wsvn/?sc=1&rev=69969
Log:
make updates per discussion via the list

Modified:
    website/policy.pod

Modified: website/policy.pod
URL: http://svn.debian.org/wsvn/website/policy.pod?rev=69969&op=diff
==============================================================================
--- website/policy.pod (original)
+++ website/policy.pod Sun Feb 27 18:26:54 2011
@@ -27,13 +27,15 @@
 
 =item 4. L<debian/watch handling|/"debian/watch handling">
 
-=item 5. L<Debian Maintainers practice|/"Debian Maintainers practice">
-
-=item 6. L<Release Process|/"Release Process">
-
-=item 7. L<Authors|/"Authors">
-
-=item 8. L<License|/"License">
+=item 5. L<Package Naming Policy|/"Package Naming Policy">
+
+=item 6. L<Debian Maintainers practice|/"Debian Maintainers practice">
+
+=item 7. L<Release Process|/"Release Process">
+
+=item 8. L<Authors|/"Authors">
+
+=item 9. L<License|/"License">
 
 =back
 
@@ -178,6 +180,80 @@
 scanning /(by-)module/ ones; author-based URLs become invalid as soon as
 there's a change in maintainership.)
 
+=head1 Package Naming Policy
+
+Where possible, packages should be named in a consistent manner, per the
+Debian Perl Policy, section 4.2: Module Package Names.
+
+Packages are named differently depending on whether their primary purpose
+is considered to be a B<library> or an B<application>. The Comprehensive
+Perl Archive Network (CPAN) is the upstream source of the great majority
+of our packages. CPAN's notion of a "distribution" is roughly compatible
+with Debian's notion of a "package", and so, packages are generally named
+after the distributions they came from.
+
+=head2 Libraries
+
+Suppose there is a hypothetical package called I<Widget::Factory>, which is
+a library that exposes an interface for other Perl programs. This package
+also contains a well-known application called I<widgetmaker>. In this case,
+we should:
+
+=over 4
+
+=item 1.
+
+Have a source package called I<libwidget-factory-perl>
+
+=item 2.
+
+Produce a single binary package: B<libwidget-factory-perl>
+
+=item 3.
+
+Set up the B<libwidget-factory-perl> binary package so that it also:
+
+  Provides: widgetmaker
+
+=back
+
+Some consideration is required when other packages may place dependencies
+on the application component of a package, since a virtual package (via
+Provides) will not allow for version dependencies to be specified. In this
+case, we can provide a separate binary package for the application.
+
+=head2 Applications
+
+Occasionally, we encounter Perl distributions that are intended to be used
+as standalone applications, rather than libraries. These distributions are
+frequently, but not always, in the App:: namespace. Developers must use
+their own judgment to decide if this is the case, but if there is any doubt,
+the issue should be discussed on the mailing list.
+
+Suppose there is a hypothetical distribution called I<Robot::Maker>, which
+is a suite of software assisting with the design of robot, best known by
+its users as I<robotmaker>. Since this is an application, we should:
+
+=over 4
+
+=item 1.
+
+Produce a source package called I<robotmaker>
+
+=item 2.
+
+Produce a binary package called B<robotmaker>
+
+=item 3.
+
+If other libraries depend on the interface provided by library components
+in this package, but these files are distributed in the same upstream
+distribution, then we should also produce a binary package called:
+B<librobot-maker-perl> or similar, which will be a dependency of the
+B<robotmaker> package.
+
+=back
+
 =head1 Debian Maintainers practice
 
 The Debian project has adopted the Debian Maintainers (DM) concept (cf.
@@ -212,6 +288,8 @@
 
 =item * Gregor Herrmann
 
+=item * Jonathan Yu
+
 =back
 
 =head1 LICENSE




More information about the Pkg-perl-cvs-commits mailing list