view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        In addition, you must meet additional requirements for working with
        the different types of archives as described next.

    In each case (except for obaining a module from a local directory), once
    you have obtained the archive, you need to be able to extract it.

    To do this, you need to meet the system requirements for the appropriate
    type of archive:

    .tar, .tar.gz, .tgz files
        You need to be able to run the system 'tar' command, or be able to
        load one of the perl modules:

           Archive::Extract
           Archive::Tar

        These modules will make use of other modules to handle .gz or .bz2
        compression.

    .zip files
        You need to be able to run the system 'unzip' command, or be able to
        load one of the perl modules:

           Archive::Extract
           Archive::Zip

    Once the package is obtained, in some cases it may be necessary to apply
    patches or run a script in it to fix things that make it not suitable
    for packaging.

PARSE VARIOUS PERL MODULES FILES FOR NECESSARY INFORMATION
    Building an RPM correctly involves getting a great deal of information
    from the module. We have to know what features are provided by this
    module, what features are required by the module to run, as well as the
    description of the module, the author, etc.

    This information can be obtained by a number of different files
    including:

    Makefile.PL, Build.PL
        Currently, these are only used to determine how the module should be
        built. Although they typically contain a great deal more
        information, it is written as perl code and there is no reasonable
        way to get the information from them.

        However, one of the steps done by this script is to actually build a
        Build script or Makefile (this ensures that the perl module can be
        correctly built), and information can be extracted from them since
        they do follow regular formats.

    META.json, MYMETA.json
        For a description of the type of data stored here, please refer to
        the CPAN-Meta documentation on CPAN.

        In order to interpret a JSON file, you have to be able to load one
        of the following perl modules:

           Parse::CPAN::Meta 1.40
           JSON
           JSON::XS
           JSON::PP
           JSON::DWIW

        Most of the information can be obtained from a complete JSON file.

    META.yml, MYMETA.yml
        For a description of the type of data stored here, please refer to
        the CPAN-Meta documentation on CPAN.

        In order to interpret a YAML file, you have to be able to load one
        of the following perl modules:

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

        Most of the information can be obtained from a complete YAML file.

    Pod file
        In most instances, some of the information (primarily the summary
        and description of the module) must be obtained from a pod document.
        This will require one of the modules:

           Pod::Select
           Pod::Simple::TextContent

        The script will need to determine which POD file to get this
        informaion from (the primary POD file for the package). Most of the
        time, the script is able to determine which file to use, but if it
        fails, it can be manually specified using the --mainpod option.

BUILD THE PACKAGE
    The next step is to actually build the module.

    This step is a departure from the way cpanspec and cpan2rpm work. In
    both of these scripts, the SPEC file contains the procedure for building
    the perl module, but it is never tested to see if it works.

    This has a couple significant advantages:

    It ensures that the package builds
        A number of perl modules cannot be built automatically because the
        scripts are interactive. Unfortunately, the RPM build process does
        not handle this well, so what you end up with is a hanging process
        that (eventually) you will have to kill by hand. In other cases, the
        build process fails for other reasons.

        When the build process is put in the SPEC file untested, the RPM
        build process will either fail or hang.

        This script avoids many of those problems.

    It generates additional meta data
        Both cpanspec and cpan2rpm would interpret the Makefile.PL and
        Build.PL scripts directly to obtain information from them. Since
        there is no guarantee that these scripts follow any convention, I
        considered this a very poor option.

        By actually building the module, it creates either a Makefile or a

README  view on Meta::CPAN

    or directly in the RPMS directory. <arch> is typicall something like
    'noarch' or 'x86_64'.

CONFIG FILE
    A config file can be created which sets options on a per-module basis.
    It can be either a YAML file (ending in .yaml or .yml) or a JSON file
    (ending in .json).

    A sample YAML file is:

       ---
       Crypt::SSLeay:
          - --config=--default

       Foo::Bar:
          - --name Foobar

    Each line should contain one option of any of the forms:

       --opt=val
       --opt val
       -o    val

    If val contains spaces, you should NOT put quotes around it. Use:

       --summary This is the summary

    instead of:

       --summary "This is the summary"

SYSTEM REQUIREMENTS
    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