Bug#114920: PROPOSAL] remove foolish consistence in perl module names
ivan wrote:
> 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'.
Apt will honour provides when installing a package.
root@silk:/home/joey>apt-get install libmail-perl
Reading Package Lists... Done
Building Dependency Tree... Done
Note, selecting libmailtools-perl instead of libmail-perl
As for dselect, all this needs is full-text-search of package
descriptions in dselect (which is implemented already, and in CVS I
think), and then mentioning what modules are provided in the
description.
> "/" in dselect and search in other package managers is an acceptable
> casualty to me, but it should be mentioned.
Ok, consider it mentioned (or do you mean mention it in policy?).
> 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.
... As opposed to, say, downloading the application on the
non-debian/stable system and following its regular installation
instructions.
I think this is out of scope of the purpose of debian package names, and
if it's the best you can do, I don't think it's worth shooting down this
porposal for.
> 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_.
That's a good point and I guess we should fix that in the perl policy.
--
see shy jo
Reply to: