Skip Menu |
 

This queue is for tickets about the MailTools CPAN distribution.

Report information
The Basics
Id: 120905
Status: resolved
Priority: 0/
Queue: MailTools

People
Owner: Nobody in particular
Requestors: NICZERO [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.18
Fixed in: (no value)



Subject: Broken packaging
Download (untitled) / with headers
text/plain 964b
The way MailTools is packaged causes problems for installers. The problem stems from its entry in perllocal.pod after installation. =head2 Fri Aug 19 11:40:08 2016: C<Module> L<Mail|Mail> Anything that then parses that file will lead to problems because there is no package or module matching 'Mail'. ! Finding Mail on cpanmetadb failed. ! Finding Mail () on mirror http://www.cpan.org failed. ! Couldn't find module or a distribution Mail I believe there is a rule that any package that declares NAME => X should include a module X.pm. [sorry -- can't find a link to such rule] ( DISTNAME => 'MailTools' , VERSION => '2.18' , NAME => 'Mail' Possible fixes: a. Include a file called Mail.pm, or b. Nominate an existing module (eg Mail::Header) to represent the package. Note that registering 'MailTools' as the installed module won't solve the problem because tools like cpanminus install module names not package names. thanks, Nic
Download (untitled) / with headers
text/plain 327b
The docn for ExtUtils::MakeMaker offers this, though it doesn't say _why_ it matters. "NAME" must be a valid Perl package name and it must have an associated ".pm" file. For example, "Foo::Bar" is a valid "NAME" and there must exist Foo/Bar.pm. Any XS code should be in Bar.xs unless stated otherwise.
Subject: Re: [rt.cpan.org #120905] Broken packaging
Date: Mon, 3 Apr 2017 16:13:59 +0200
To: Nic Sandfield via RT <bug-MailTools [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
Download (untitled) / with headers
text/plain 993b
* Nic Sandfield via RT (bug-MailTools@rt.cpan.org) [170403 14:06]: Show quoted text
> Queue: MailTools > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=120905 > > > The docn for ExtUtils::MakeMaker offers this, though it doesn't say _why_ it matters. > > "NAME" must be a valid Perl package name and it must have an associated > ".pm" file. For example, "Foo::Bar" is a valid "NAME" and there must > exist Foo/Bar.pm. Any XS code should be in Bar.xs unless stated > otherwise.
Yes, it documents the current rules to start a new distribution. You will not be able to claim a new namespace without complying to it. That's a "PAUSE" thing. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
CC: ;
Subject: Re: [rt.cpan.org #120905] Broken packaging
Date: Mon, 3 Apr 2017 16:02:33 +0200
To: Nic Sandfield via RT <bug-MailTools [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
Download (untitled) / with headers
text/plain 1.5k
* Nic Sandfield via RT (bug-MailTools@rt.cpan.org) [170403 13:40]: Show quoted text
> Mon Apr 03 09:39:31 2017: Request 120905 was acted upon. > Transaction: Ticket created by NICZERO > Queue: MailTools > Subject: Broken packaging > Broken in: 2.18 > Requestors: NICZERO@cpan.org > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=120905 > > > > The way MailTools is packaged causes problems for installers. > Anything that then parses that file will lead to problems because > there is no package or module matching 'Mail'.
New distributions must have a name which is the same as one of the packages included. This prevents abuse by claiming other people's namespaces by new modules. There are, however, quite a number of old packages which started before that requirement. If tools cannot cope with the existing and legal situation, they are broken. When I add a module Mail::Tools, people will start making dependencies to it. This may cause all kinds of problems is existing distributions and installations. I have to sleep a few nights of that to be able to judge on the consequences. In my experience, any change I make to this -over 20 years old: 1995- module causes head-aches to maintainers of long overdue systems (and me). So, I really hessitate make any change. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Download (untitled) / with headers
text/plain 762b
On 2017-04-03 07:25:52, solutions@overmeer.net wrote: Show quoted text
> When I add a module Mail::Tools, people will start making dependencies > to it. This may cause all kinds of problems is existing distributions > and installations. I have to sleep a few nights of that to be able to > judge on the consequences.
People should be declaring dependencies on the exact module(s) that they use -- e.g. Mail::Util or Mail::Send. You could use any of the existing module names as the NAME in Makefile.PL; you do not need to create a new one. You certainly could create lib/MailTools.pm that is nothing but a bit of documentation; if people declare a dependency on that and then you later break up the distribution into pieces, then it is their code that is broken, not yours.
Download (untitled) / with headers
text/plain 254b
I have not seen anywhere that the ancient package bundles have been deprecated. Maybe I missed it. The issue addressed in this ticket has to do with that. Starting from 2.19, the distribution includes MailTools.pm so behaves like a non-bundle as well.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.