Bug#114920: PROPOSAL] remove foolish consistence in perl module names

[Joey Hess <joeyh@debian.org>]

ivan wrote:
> I object to this proposal for the reasons outlined below.  I _do_ agree
> with the spirit of the proposal and would support it if the issues below
> were resolved.
> 
> The amendment should explicitly specify a maximum length rather than the
> ambiguous "too long and cumbersome".  This should be a general policy
> clarification, not just a perl policy change.

Policy is only useful if the reader applies common sense when reading
it. 10 characters may be "too long and cumbersome" for a very often-used
perl module package which people install by hand, while 30 characters is
not overly long for a very special-purpose perl module package that is
only ever pulled in by dependancies.

I might support a general proposal for an absolute upper bound on
package name size, but that would be another proposal (feel free to make
it, I'm sure the flame war would be interesting). And I would want my
"too long and cumbersome" text to remain nontheless, as its purpose is
*not* to enforce an absolute upper bound on package name suze, but to
make the maintainer *think*, "is this package name going to be too long
and cumbersome?".

I think that getting people to think often results in better systems than
just forcing them to memorize a pile of rules.

> Current perl policy provides an unambiguous mapping from CPAN distribution
> name to debian package name, and vice-versa.  If I know the name of the
> CPAN module distribution I want, I know the name of the debian package
> which provides it.  If I know the name of a debian package, I know the
> CPAN module distribution it provides.  I find this *very* useful.  The
> amendment as proposed would remove this ability. 

It seems you missed the fact that provides will allow the CPAN -> package
mapping. The reverse mapping is IMHO not too useful. Provide a few examples
of when you'd need to be able to do that mapping automatically, please.

Also, bear in mind that this reverse mapping you're so keen on is not
required by current debian perl policy[1]. Imagine a package that
contains 3 perl modules, Foo::Bar, Foo::Baz, and Xyzzy. Foo::Bar is, in
the eyes of the maintainer (but maybe not in the eyes of the user) the
"primary module provided", so the package is named libfoo-bar-perl. The
maintainer, following current perl policy, decides to go ahead and make
it provide libfoo-baz-perl and libxyzzy-perl as well. Now given the
name of the libfoo-bar-perl package, how do you automatically know the
CPAN modules it provides? You don't; you know at most one of them.

-- 
see shy jo

[1] Which is:

     Perl module packages should be named for the primary module provided.
     The naming convention for module `Foo::Bar' is `libfoo-bar-perl'.
     Packages which include multiple modules may additionally include
     provides for those modules using the same convention.