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

2001-10-10 Thread Joey Hess
Andrew Suffield wrote: > On Tue, Oct 09, 2001 at 01:35:06PM -0400, Joey Hess wrote: > > > > Or the package's name may > ^^^ > > > > be an abbreviated version, and the longer name put in the Provides > > > > field. > > > > > > Require is probably too strong, but

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

2001-10-10 Thread Andrew Suffield
On Tue, Oct 09, 2001 at 01:35:06PM -0400, Joey Hess wrote: > > > Or the package's name may ^^^ > > > be an abbreviated version, and the longer name put in the Provides > > > field. > > > > Require is probably too strong, but I suggest this should instead read: >

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

2001-10-09 Thread ivan
On Tue, Oct 09, 2001 at 03:56:00PM -0400, Joey Hess wrote: > 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. Okay, please add the descri

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

2001-10-09 Thread Joey Hess
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-g

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

2001-10-09 Thread ivan
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 max

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

2001-10-09 Thread Joey Hess
Andrew Suffield wrote: > > > I suggest the amendment require that the package Provide the full > ^^^ > > > name, if it doesn't use it as its real name. > > > > It already does. > > It currently suggests it: > > > Or the package's name may > > be an abbreviated

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

2001-10-09 Thread Joey Hess
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". Thi

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

2001-10-09 Thread Andrew Suffield
On Tue, Oct 09, 2001 at 10:37:25AM -0500, Colin Watson wrote: > On Tue, Oct 09, 2001 at 11:11:44AM +0100, Andrew Suffield wrote: > > On Tue, Oct 09, 2001 at 01:05:09AM -0700, ivan wrote: > > > Current perl policy provides an unambiguous mapping from CPAN distribution > > > name to debian package na

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

2001-10-09 Thread Colin Watson
On Tue, Oct 09, 2001 at 11:11:44AM +0100, Andrew Suffield wrote: > On Tue, Oct 09, 2001 at 01:05:09AM -0700, ivan wrote: > > 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 distrib

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

2001-10-09 Thread Andrew Suffield
On Tue, Oct 09, 2001 at 01:05:09AM -0700, ivan wrote: > 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.

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

2001-10-09 Thread ivan
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 po