Bug #120905 for MailTools: Broken packaging

Mon Apr 03 09:39:31 2017 NICZERO [...] cpan.org - Ticket created

Subject:

Broken packaging

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

Mon Apr 03 10:06:20 2017 NICZERO [...] cpan.org - Correspondence added

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.

Mon Apr 03 10:14:27 2017 solutions [...] overmeer.net - Correspondence added

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>

* 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

Mon Apr 03 10:14:27 2017 The RT System itself - Status changed from 'new' to 'open'

Mon Apr 03 10:25:52 2017 solutions [...] overmeer.net - Correspondence added

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>

* 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

Mon Jul 31 19:07:17 2017 ether [...] cpan.org - Correspondence added

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.

Tue Aug 22 07:48:20 2017 MARKOV [...] cpan.org - Correspondence added

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.

Tue Aug 22 07:48:21 2017 MARKOV [...] cpan.org - Status changed from 'open' to 'resolved'