Re: Applications in the Perl Group
> I'd prefer to have the rules written down before using them; could
> you provide the wording as a patch to policy.pod?
Certainly:
Index: policy.pod
===================================================================
--- policy.pod (revision 69717)
+++ policy.pod (working copy)
@@ -27,14 +27,16 @@
=item 4. L<debian/watch handling|/"debian/watch handling">
-=item 5. L<Debian Maintainers practice|/"Debian Maintainers practice">
+=item 5. L<Package Naming Policy|/"Package Naming Policy">
-=item 6. L<Release Process|/"Release Process">
+=item 6. L<Debian Maintainers practice|/"Debian Maintainers practice">
-=item 7. L<Authors|/"Authors">
+=item 7. L<Release Process|/"Release Process">
-=item 8. L<License|/"License">
+=item 8. L<Authors|/"Authors">
+=item 9. L<License|/"License">
+
=back
=head1 Mandatory mailing lists and such
@@ -178,6 +180,93 @@
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. Keeping
+with this convention helps packages have sensible names and ensures that
+they are easy to find.
+
+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 there are reverse dependencies on the
+application component of a package, since a virtual package (via Provides)
+will not allow for a version dependency to be specified. In this case, we
+can opt instead to:
+
+=over 4
+
+=item 1.
+
+Produce a source package called I<libwidget-factory-perl>
+
+=item 2.
+
+Produce two binary packages: B<libwidget-factory-perl> and B<widgetmaker>
+
+=back
+
+=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 +301,8 @@
=item * Gregor Herrmann
+=item * Jonathan Yu
+
=back
=head1 LICENSE
Reply to: