view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    This script will try to function under many different situations, and it
    will often try multiple methods to accomplish a task, and many of those
    methods will be available on any common linux configuration. As such, a
    rigorous list of system requirements is overly complicated and won't be
    listed here. In the event that the script fails, it will list the
    methods tried and you can make sure that one of them will function on
    your host.

    The most common requirements will be listed here. In all probability, if
    you meet these requirements, this script will run.

    Since the most common way to obtain a module will be from CPAN, you will
    need one of the following modules installed and correctly configured:

       CPAN
       CPANPLUS

    To make sure it's configured, make sure you can run cpan or cpanp at the
    command line and have it work.

    If you will be applying patches to a package, you will need the patch
    command.

    You also need to be able to read both YAML and JSON files included in
    almost every module. This means that you will need one JSON module
    installed out of the following:

       JSON
       JSON::XS
       JSON::PP
       JSON::DWIW

    and one YAML module from the following:

       YAML
       YAML::Syck
       YAML::XS
       YAML::Tiny

    You will also need to be able to examine POD files using one of the
    following modules:

       Pod::Select
       Pod::Simple::TextContent

    You'll should have:

       Module::Build
       Module::Build::Tiny
       ExtUtils::MakeMaker

    installed in order to build modules that use the Build.PL and
    Makefile.PL scripts (both Module::Build and Module::Build::Tiny are
    supported).

    In order to build the rpm, you need the rpmbuild program.

    This script also relies on the strace program. This is necessary because
    many Makefile.PL and Build.PL scripts are interactive so when you run
    them, they hang waiting for input. Unfortunately, I was not able to find
    any pure perl way to run a program as a child (or in a thread) and
    monitor it to see if it's still running because it's doing work, or
    still running because it's waiting on user input. Though somewhat crude,
    strace can be used to determine that.

    In order to sign packages, you must have the gpg program installed, and
    you must have a key set up to sign with. In order to do this
    non-interactively, you also need either the Expect module or the expect
    program installed.

    In order to install the package, you either must be running as root, or
    have the sudo program. The sudo command may be interactive, depending on
    how you have it set up.

    In order to install RPMs in a yum repository, the repository must exist.

HISTORY
    This script is based loosely on Erick Calder's cpan2rpm script and
    Steven Pritchard's cpanspec script. Initially, I set out to modify one
    or the other of them, but I found that the modifications that I felt
    necessary were extensive enough that I decided a fresh implementation
    was both faster and cleaner.

    cpan2rpm
        cpan2rpm had basically the full functionality that I wanted. It
        would download a module, write a spec file for it, create an RPM,
        and then install it. The only functionality that was missing was
        some simple functionality to add it to a local yum repository. That
        would have been very simple to add. However, it suffered from
        several other significant problems.

        cpan2rpm is old. It has not been supported since 2003. It has
        virtually no support for modules built using Build.PL scripts, and
        adding it would have been quite complicated.

        cpan2rpm is also not written as cleanly, or in a style that I'd like
        to maintain, so it would take a bit of cleaning up to turn it into
        something I'd want to maintain.

        The main problem though is how it gets information from the
        Makefile.PL script. In order to get all of the information necessary
        to create a SPEC file, there's a lot of information about the module
        that needs to be examined. Much of that information is stored in the
        various META files in any new module distribution. None of that is
        used in cpan2rpm (which predates most of them), so that would have
        to be added. However, even with the META files, some information
        comes from the Makefile.PL (or Build.PL script) such as the default
        install location.

        Since the data is in a script, cpan2rpm tries to be intelligent
        about extracting the information. It loads in the Makefile.PL
        script, modifies it (by turning 'exit' into 'return') and evals it.
        The theory is that by eval'ing it, you end up with the appropriate
        data structure that you can examine.

        The modifications that it makes are completely unjustified though.
        It makes drastic assumptions about what the Makefile.PL file looks
        like, and I can think of any number of cases where turning 'exit'
        into 'return' won't produce the result you want.

        As such, cpan2rpm's handling of the Makefile.PL file needed to be