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. [EMAIL PROTECTED]:/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
