App-Fetchware

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

      Fetchwarefile syntax checking. No parsing of Perl is done as that's best
      left to perl itself.
    - The upgrade() subroutine was also added to the Fetchware API allowing
      Fetchware extensions to easily change Fetchware's definition of when your
      Fetchware package should be upgraded.
    - Added support for these new API subroutines to Fetchware's example
      Fetchware extension App::FetchwareX::HTMLPageSync.
    - Added perl 5.10.1 as an "official" dependency. Each Perl file always had a
      "use 5.010001;" line, but it was never declared in dist.ini.
    - Many minor doc fixes and tweaks, and the Fetchware extension documentation
      was updated to cover the new API subroutines new(), new_install(),
      check_syntax(), and upgrade().

1.010     2013-12-14 04:10:18 America/New_York
    - Fixed github#4 by added a more reliable checksum parser that should be
      generic enough to parse anything simple and reasonable.
    - Fixed a bug related to github#4 that caused ftp timestamp parsing to fail
      if file listing had symbolic links in it.
    - Also fixed the "uninitialized variables" bug again. The previous fix was
      horrible. It took a few tries to figure it out, and almost resulted in
      breaking fetchware's command line interface again, but my command line

README  view on Meta::CPAN

WHY SHOULD I USE FETCHWARE INSTEAD OF MY OWN PLATFORM'S PACKAGE MANAGER?

Fetchware should be used if you want to build those same software packages from
source code, and be able to specify your own configuration options to
configure that software as you want instead of how that package's maintainer
wants it to be configured. Furthermore, Fetchware leaves you in control of
creating the actual Fetchware package, because you just need the Fetchwarefile,
and that is enough to build and install a Fetchware package. This means that
instead of using something like Fedora/RHEL's EPEL, where you're a slave to each
individual package maintainer's schedule and ability to release updated versions
every time yet another security hole comes out, you can upgrade to latest,
secure version whenever it is released. 

However, Fetchware needs a full build environment on your server, and wherever
you install the resulting Fetchware package. This may be a limitation in some
enterprise/data center environments. However, if you set up your Fetchwarefile
properly, you can build the Fetchware package on a testing or build server, and
then only do the "make install" step on each of the production servers.

bin/fetchware  view on Meta::CPAN

    ($P_upgrade,
    $P_build_path,
    $P_download_path,
    $P_fetchware_package_path) = read_dropprivs_pipe($output);

    # Test if a new version is available again due to drop_priv() ending
    # half way through this if statement.
    if ($P_upgrade) {
        install($P_build_path);

        my $updated_fetchware_package_path
            =
            create_fetchware_package($fetchwarefile, cwd());
        vmsg <<EOM;
Created a new fetchware package for the newly installed upgraded fetchware
package [$updated_fetchware_package_path].
EOM

        uninstall_fetchware_package_from_database($P_fetchware_package_path);
        vmsg 'Uninstalled the old fetchware package from the fetchware database.';

        my $installed_fetchware_package_path
            = copy_fpkg_to_fpkg_database($updated_fetchware_package_path);
        vmsg <<EOM;
Installed new fetchware package to fetchware package database
[$installed_fetchware_package_path].
EOM

        end();

        # Return the path of the created and installed fetchware package.
        return $installed_fetchware_package_path;
    } else {

lib/App/Fetchware.pm  view on Meta::CPAN

It overrides lookup() to use a local git repo stored in the $git_repo_dir
variable. To create a repo just clone php's git repo (see
http://us1.php.net/git.php for details.). It runs git pull to update the repo,
and then it runs git tags, and ditches some older junk tags, and finds only the
tags used for new versions of php. These are sorted using the C<versonstring>
lookup() algorithm, and the latest one is returned.

download() uses C<git checkout [latesttag]> to "download" php by simply changing
the working directory to the latest tag. verify() uses git's cool C<verify-tag>
command to verify the gpg signature. unarchive() is updated to do nothing since
there is no archive to unarchive. However, because we reuse build(), archive()
must return a $build_path that build() will change its directory to. start() and
end() are also overridden, because managing a temporary directory is not needed,
so, instead, they just do a C<git checkout master> to switch from whatever the
latest tag is back to master, because git pull bases what it does on what branch
you're in, so we must actually be a real branch to update git.

=over

    # php-using-git.Fetchwarefile: example fetchwarefile using php's git repo

t/App-Fetchware-new.t  view on Meta::CPAN

        }
    );

    $fetchwarefile = edit_manually($term, $fetchwarefile);
    isa_ok($fetchwarefile, 'App::Fetchware::Fetchwarefile',
        'Test Fetchwarefile');

};


##TODO#####BUGALERT### The code below that tests cmd_new() has *not* been updated yet to
##TODO###the Fetchware refactor where cmd_new()'s behavior was moved into App::Fetchware
##TODO###as the new API subroutines new() and new_install(). So, if you wish to test the
##TODO###code below, you'll have to fix it up to work how new() works after the
##TODO###refactor. Also note, the code below has been copied and pasted to become with
##TODO###basis of t/App-Fetchware-new_install.t and even the updated to work with the
##TODO###refactor, t/bin-fetchware-new.t.
##TODO####BROKEN##subtest 'test cmd_new() success' => sub {
##TODO####BROKEN##    skip_all_unless_release_testing();
##TODO####BROKEN##
##TODO####BROKEN##    plan(skip_all => 'Optional Test::Expect testing module not installed.')
##TODO####BROKEN##        unless eval {require Test::Expect; Test::Expect->import(); 1;};
##TODO####BROKEN##
##TODO####BROKEN##    # Disable Term::UI's AUTOREPLY for this subtest, because unless I use
##TODO####BROKEN##    # something crazy like Test::Expect, this will have to be tested "manually."
##TODO####BROKEN##    local $Term::UI::AUTOREPLY = 0;

t/App-FetchwareX-HTMLPageSync.t  view on Meta::CPAN

        'checked lookup()s return value for acceptable values yet again.'
    );
};

# Created here so it can be shared with install()'s subtest.
my $download_file_paths;
subtest 'test HTMLPageSync download()' => sub {
    skip_all_unless_release_testing();


    # FETCHWARE_HTTP_DOWNLOAD_URL is manually updated will break whenever a new
    # version of Apache 2.2 comes out.
    # download() wants an array ref.
    $download_file_paths = download($temp_dir,
        [ $ENV{FETCHWARE_HTTP_DOWNLOAD_URL} ]);
    note("DFP");
    note explain $download_file_paths;

    ok(@$download_file_paths == 1,
        'checked download() correct number of files');