1. Forum
  2. Usenet
  3. COMP.LANG.PERL.MISC

  • Are all CPAN modules supposed to be listed on metacpan.org?

    From Tim Landscheidt@21:1/5 to All on Fri Mar 22 08:11:22 2024
    Hi,

    I'm looking into broken URLs of Fedora packages of (inter
    alia) CPAN modules, in the following picking https://src.fedoraproject.org/rpms/perl-Config-IniHash as a
    random example.

    This Fedora package refers to
    https://metacpan.org/release/Config-IniHash which redirects
    to https://metacpan.org/dist/Config-IniHash which is 404.

    The source URL however, https://cpan.metacpan.org/authors/id/J/JE/JENDA/Config-IniHash-3.01.01.tar.gz, works nicely, as does some metadata file at https://www.cpan.org/modules/by-authors/id/J/JE/JENDA/Config-IniHash-3.01.01.meta.

    If I go to https://metacpan.org/author/JENDA, Config-IniHash
    is not listed there. If I search for "Config-IniHash" (https://metacpan.org/search?size=20&q=Config-IniHash) or
    "Config::IniHash"
    (https://metacpan.org/search?size=20&q=Config%3A%3AIniHash)
    on metacpan.org, I don't get any pertinent results.

    Therefore I'm interested if this is the expected result or
    some fault at (meta)cpan.org and thus who I need to contact
    to get it fixed. Does the module author have to click some
    button to trigger the inclusion in the database? Are all
    modules available at cpan.org supposed to be listed at
    metacpan.org?

    TIA,
    Tim

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Dorner@21:1/5 to Tim Landscheidt on Fri Mar 22 19:38:07 2024
    Hi Tim!

    Tim Landscheidt <[email protected]> writes:
    Hi,

    I'm looking into broken URLs of Fedora packages of (inter
    alia) CPAN modules, in the following picking https://src.fedoraproject.org/rpms/perl-Config-IniHash as a
    random example.

    This Fedora package refers to
    https://metacpan.org/release/Config-IniHash which redirects
    to https://metacpan.org/dist/Config-IniHash which is 404.

    The source URL however, https://cpan.metacpan.org/authors/id/J/JE/JENDA/Config-IniHash-3.01.01.tar.gz,
    works nicely, as does some metadata file at https://www.cpan.org/modules/by-authors/id/J/JE/JENDA/Config-IniHash-3.01.01.meta.

    This use an old standard for the META-spec, which should not be a
    problem. (I have a very old one also using 1.2 without problems as
    well.) But the 1st line looks a bit incomplete as the spec says:

    |The first line of a META.yml file should be a valid YAML document
    |header like "--- #YAML:1.0".

    Maybe that's the problem? (Just a wild guess as I'm not really familiar
    with the old spec's details.)

    If an author releases a new module (or new version) on PAUSE, an indexer analyses the package including the META-spec (and usually sends a mail
    to the author that everything went well, what it indexed etc.). But
    this process can sometimes fail and the author has to restart it
    manually. (I never had any problems though, I just read about it.)

    Does the module author have to click some button to trigger the
    inclusion in the database?

    Normally it gets added fully automatically, if the META-spec is correct
    and the PAUSE server don't run into problems.

    Are all modules available at cpan.org supposed to be listed at
    metacpan.org?

    At least those that appear as "name" in the META-spec, yes.

    Just my 2 cents.

    Best regards, Thomas
    --
    Address is only valid for short time!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eric Pozharski@21:1/5 to Thomas Dorner on Sat Mar 23 16:03:07 2024
    with <[email protected]> Thomas Dorner wrote:
    Tim Landscheidt <[email protected]> writes:

    I'm looking into broken URLs of Fedora packages of (inter alia) CPAN
    modules, in the following picking
    https://src.fedoraproject.org/rpms/perl-Config-IniHash as a random
    example.
    *SKIP* [ 14 lines 2 levels deep]
    |The first line of a META.yml file should be a valid YAML document
    |header like "--- #YAML:1.0".
    Maybe that's the problem? (Just a wild guess as I'm not really
    familiar with the old spec's details.)
    If an author releases a new module (or new version) on PAUSE, an
    indexer analyses the package including the META-spec (and usually
    sends a mail to the author that everything went well, what it indexed
    etc.). But this process can sometimes fail and the author has to
    restart it manually. (I never had any problems though, I just read
    about it.)

    Disclaimer: I'm not affiliated with cpan-people either, what follows is
    my speculation. Config-IniHash has been added to CPAN ~20070125 and
    about ~201712## it has been "removed". However, what "removed" means in Perl-land is "removed from indexes" or de-indexed. Files themselves
    must be scheduled for purge by author (it means: personally by author).
    That act of care has never happened.

    From Perl, perl, and CPAN perspective Config-IniHash doesn't exist. It
    is possible that some cruft has been accumulated in various places on
    the span of 15y. I'm pretty much certain there's more.

    *CUT* [ 15 lines 2 levels deep]

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bouras George@21:1/5 to Tim Landscheidt on Mon May 20 09:52:54 2024
    On 22/3/2024 10:11 π.μ., Tim Landscheidt wrote:
    Hi,

    I'm looking into broken URLs of Fedora packages of (inter
    alia) CPAN modules, in the following picking https://src.fedoraproject.org/rpms/perl-Config-IniHash as a
    random example.



    no problem here

    cpanm --version
    cpanm (App::cpanminus) version 1.7046 (/usr/bin/vendor_perl/cpanm)
    perl version 5.038002 (/usr/bin/perl)

    cpanm --test-only Config::IniHash

    ! Finding Config::IniHash on cpanmetadb failed.
    Working on Config::IniHash
    Fetching http://cpan.metacpan.org/authors/id/J/JE/JENDA/Config-IniHash-3.01.01.tar.gz ... OK
    Configuring Config-IniHash-3.01.01 ... OK
    Found dependencies: Hash::Case, Hash::WithDefaults
    Working on Hash::Case
    Fetching
    http://www.cpan.org/authors/id/M/MA/MARKOV/Hash-Case-1.05.tar.gz ... OK Configuring Hash-Case-1.05 ... OK
    Building and testing Hash-Case-1.05 ... OK
    Successfully tested Hash-Case-1.05
    Working on Hash::WithDefaults
    Fetching http://www.cpan.org/authors/id/J/JE/JENDA/Hash-WithDefaults-0.04.tar.gz
    ... OK
    Configuring Hash-WithDefaults-0.04 ... OK
    Building and testing Hash-WithDefaults-0.04 ... OK
    Successfully tested Hash-WithDefaults-0.04
    Building and testing Config-IniHash-3.01.01 ... OK
    Successfully tested Config-IniHash-3.01.01

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)