in reply to Re^3: Any reason to have documentation-only *.pm file instead of *.pod for CPAN distro?
in thread Any reason to have documentation-only *.pm file instead of *.pod for CPAN distro?

The existence of a directory doesn't matter at all to how things are indexed. And subdirectories (or sub-packages) don't imply any relationship between namespaces. Claiming the package MCE::Core::Worker doesn't give you permissions on MCE::Core.

Until the latest release, there was no MCE::Core package, only a .pod file. So it was not indexed, and had no permissions attached to it. It would have been possible for a bad actor to claim that namespace and upload any tarball they wanted for it.

It is possible to control this through data in a META.json file, but usually that data is automatically generated. And it can still be confusing for a dist to claim it provides a module that doesn't actually exist because it's only a .pod file.

  • Comment on Re^4: Any reason to have documentation-only *.pm file instead of *.pod for CPAN distro?

Replies are listed 'Best First'.
Re^5: Any reason to have documentation-only *.pm file instead of *.pod for CPAN distro?
by Anonymous Monk on Jan 04, 2025 at 10:19 UTC

    I'm new to POD and pod/pm interaction and precedence, please forgive my silly questions. I've just created Acme::AAA "distribution" tarball where I also included Cwd.pod to "hijack" a core module documentation. Then cpanm'd this tarball, checked with perldoc Cwd, and it printed "evil" content of my POD, not documentation extracted from Cwd.pm. Apart from, apparently, nothing prevents a "bad actor" to lure people to install something similar, but if uploaded to CPAN, what the https://metacpan.org/pod/Cwd would display then "globally"?

    While we are at it, looks like perldoc link in SEE ALSO section of perlpod and elsewhere is broken in effect, it shows some obsolete Spanish translation.

[reply]
[d/l]
[select]
[reply]
[reply]

In Section Seekers of Perl Wisdom