Bug#114920: PROPOSAL] remove foolish consistence in perl module names
On Tue, Oct 09, 2001 at 01:31:33PM -0400, Joey Hess wrote:
> 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).
I very well may; after uploading the longest package in the distribution
the irony of proposing that amendment might be too much to pass up. First
you'd have to convince me mapping problems below are fixed or fixable, I
think.
> 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.
In this specific case, if the problem below is not solved, an explicit
maximum length would at least let the person searching for the .deb
package that corresponds to a CPAN distribution name know when to stop
looking for libfoo-too-long-bar-perl and to start looking for an
abbriviated package name. If the problem below is not solved,
specifying an explicit maximum length and a standard abbriviation method
will at least make it possible (if more cumbersome) to find the debian
package for a particular CPAN distribution name.
(If the problem were to be solved, then this is irrelevant)
> > 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.
I was not sufficiently clear in my wording if what you got from it was
that I missed this fact.
Provides: will allow the CPAN->package mapping for *dependencies*. There
is no provision for "/" in dselect (or the equivalent in other package
managers) or `apt-get install libfoo-bar-perl'. This is something I do
*often*, and I'd say that other Perl programmers who have switched from
CPAN to .deb for their module need do also. At a minimum, you'd want
something to grovel through the Provides: so you can do something not
unlike:
apt-get install `cpan2deb Foo::Bar`
for proof-of-concept.
"/" in dselect and search in other package managers is an acceptable
casualty to me, but it should be mentioned. If I were being really
pie-in-the-sky I'd wish for the ability to search for Perl (Java,
Python, etc.) names with a special option (or just "/") in dselect,
and an equivalent in other package managers.
> 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.
I find it useful to do manually, and I disagree that automatic usage is
the only useful use.
An example of where it is useful to have this one-to-one mapping:
Consider the case where I find a Perl application I like/find
useful/whatever on my desktop box running unstable or testing. The
application is not yet in stable. I then wish to install this application
on box running Debian stable or a non-debian OS. To determine which CPAN
distributions I need, I can currently look at the Depends: of the package
to determine this information unambiguously.
(Tangential but relevant: the build procedure of most modules is no longer
compatible with stable; most of them no longer build on stable.
Therefore when installing an application from unstable/testing on stable,
backporting modules from unstable is far more complicated than CPAN and
*not* a matter of a simple apt-get source and dpkg-buildpackage)
The amendment as proposed breaks the ability to determine this
information. Given the Depends: example from the above paragraph, how
would you determine if a lib-*-perl module was an abbriviated name or not?
How would you determine which Provides: in the package description
corresponds to the CPAN distibution name? (note that CPAN distribution
name != CPAN module name in all cases - more on that below).
> 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.
Actually (and here policy is out of sync with reality and should be fixed
- a separate problem), debian packages are typically named
after the CPAN _distribution name_, not the _module name_.
Two examples are libcgi-pm-perl and libmailtools-perl. libcgi-pm-perl
provides the CGI module, not the CGI::PM module, but it is correctly named
libcgi-pm-perl after the CGI.pm CPAN distribution:
http://search.cpan.org/search?dist=CGI.pm
libmailtools-perl provides a bunch of Mail:: modules such as Mail::Send,
Mail::Address and Mail::Internet, not the MailTools module or MailTools::
modules. Again, it correctly named after the MailTools CPAN distribution:
http://search.cpan.org/search?dist=MailTools
You've also mixed them up a bit reading my objections; understandable,
considering the confusion of current policy on this issue. Above I'm
talking about one-to-one correspondance between debian package name and
CPAN distribution name, *not* module name.
> [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.
--
_ivan
Reply to: