Re: MetaCPAN Issues inconsistent links?

[Corion]

Yes, this is configurable through Makefile.PL resp. the META.json file in the distribution.

Most likely, the respective metainformation in these distributions is incomplete, but I don't see why the link for HTTP, which lives in the mod_perl distribution should go anywhere other than the mod_perl distribution.

When I visit the metacpan page for DB, it points to https://rt.perl.org/, (not http://rt.cpan.org), which is the correct link, because DB.pm is the Perl debugger, which is distributed with Perl itself and where Perl is upstream.

[QM]

OK, understood. I did not realize that these were grouped by distribution. I suppose if you're going to report a bug, you either blindly trust that the "issue" or "report bug" link (depending on where you started) points to the right place, or you do some legwork and find out what the right place is. The blind method has the downside that if it's wrong, you're report could be ignored for years before the housekeeping elves come through and mumble "WTF", and possibly toss it out. But hey, you get what you pay for, well enough.

It does seem a bit strange to say "It's in the core, therefore it's all part of the monolith we call perl." But the community must have decided eons ago this is the way to do it.

Cheers,

[Corion]

Actually, most things in the core are in the core because nobody has taken it on themselves to maintain the module outside of the core. Stuff not being maintained in the core is the preferred method for most things because then you can upgrade the module without needing to upgrade the Perl version.

[QM]

Actually, most things in the core are in the core because nobody has taken it on themselves to maintain the module outside of the core.

I'm sure that's part of it. But I think it's more the case that things in the core are deemed useful and critical to a Perl distribution, such that I can do interesting things right out of the box. Orphan modules of some utility would come second.