[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Perl Policy (Was: RFS: librpc-xml-perl)



On Tue, Jun 13, 2006 at 01:19:53PM +0300, Damyan Ivanov wrote:
>After a fresh read[1] of Perl policy [...]
>[1] I realize that reading Perl policy afresh is something I had to do
>before RFS here. Sorry for wasting your time.

The problem of interpreting perl-policy from a module packager's
perspective is not yours; the document definitly needs an update.

When I updated the policy, I was deliberately vague about the actual
implementation of the Perl packaging--the intent being to provide a
definition of what a user of perl could expect[0], without tying myself
or a subsequent packager down to specific implementation detaild[1].

Now while this makes for a fine policy for the perl packages, it is
perhaps less helpful for packages which use perl, or perl modules.

After having seen some subsequent confusion as to adding dependencies on
perl-modules (don't) or perl vs. perl-base (such as this issue), perhaps
what is required is a "Best Practices", or "Rationale" appendix to the
document which outlines some of these issues (similar to the purpose of
the "Developer's Reference" to "Debian Policy").

I'd welcome a bug on debian-policy to add such an appendix to perl-policy
from a better word-smith than I who is actively maintaining Perl modules.

--bod

[0] "Only one package may contain the `/usr/bin/perl' binary and that
     package must either be `perl' or a dependency of that package (see
     Section 2.2, `Base Package')."
     
[1] The intent being that "apt-get install perl" would provide a
    working /usr/bin/perl.  Although under the current implementation
    that means ensuring that perl, perl-modules and perl-base (which
    actually contains /usr/bin/perl) are up to date.



Reply to: