Delete useless, confusing out of date comment.
Deleted crazy, confusing, out of date comment.
Added extra testing for equivilent version strings to lookup_by_versionstring().

lookup_by_versionstring() uses the numbers in program versions, such as
(2,2,4) in httpd-2.2.4.tar.bz2, but sometimes there will be files such as
CHANGES_2_2, which is shorter than 2.2.4. Because it's shorter it is "smaller,"
and therefore, can be short circuited.

This commit now does this to avoid annoying "use of uninitialized variable"
warnings. Also, those warnings may have actually been a bug, because they're
undef, and undef is 0 when used as a number, which may actually mess up how they
should be sorted.

NOTE: This commit changes the previous behavior of 2.0.0 and 2.0 being equal.
Now 2.0.0 is "bigger" than 2.0. I don't think this change is a big deal, or
would surprise anyone. If the previous behavior is wanted instead, I could
change the -1 and 1's to 0's.
Implemented and tested new upgrade() API subroutine.

The way fetchware determines if a new version is available is brittle and lame,
and might not work well in all cases, so I always wanted to give the user a way
to change how fetchware determines if the latest version is newer than the
currenlty installed version.

Now you can just hook it, and change it if your software package does not have
what fetchware calls "versionstrings" in it.

Next, I'll implement and test check_syntax() and new(), and also fix some broken
CPANTesters reports too while I'm at it.
Fixed .gitignore pattern for dzil's App-Fetchware-[version#] build directories.
Added missing upgrade to parse_fetchwarefile()'s syntax checking code.
Implement and test check_sytax() new API subroutine.

check_syntax() unifies all syntax checking into one place, and makes it
easier for fetchware extensions to also provide syntax checking, because
check_config_options() has been added to make checking for common syntax
errors in Fetchwarefiles much easier.

Note: check_sytax() does *not* check any Perl level syntax only Fetchware's
"own" syntax. No actual perl code is parsed or anything. Instead, the
Fetchwarefile is parsed using eval, and config() is run a bunch of times to
ensure that no fetchware level syntax errors exist.
Removed old crufty syntax checking in check_lookup_syntax() and build().

I also deleted the parts of their test suites that tested this syntax checking
code.
Refactored opening_message() to take an argument, so extensions can change it.

This is the first commit in what will become a series of commits changing how
cmd_new() works to covert it to a App::Fetchware API subroutine called new.

new()'s refactor will be. (This design may change as needed as it progresses.)

opening_message() - will take an arg, so extensions can use it.
analyze_lookup_listing() - will go away, and extensions will just have to call
add_mirrors() and add_verification() directly.
    - This directness coupled with add_*() returning their fetchwarefile
      additions instead of just doing them, will allow extensions to analyze
      what new()'s helpers are doing, and dicard their changes as needed if
      desired making it more flexible, then an interface that is:
        - Call the helper subroutines or not.
        - And if not be annoyed that you wind up copying and pasting parts of
          them as needed to hack your desired functionality together.
extension_name() - will just be used, so I can easily change the name of
"App::Fetchware" to your extension's name as needed in helper error messages.
new_helper() - because add_*() will return stuff the extension author will have
to call append_options_to_fetchwarefile() for each call to a add_*() API helper
subroutine. This java like boiler plate is annoying, so new_helepr() will help
you deal with it, by calling append_options_to_fetchwarefile() for you. It might
even have callbacks allowing you to use it even if you want to mess with the
return values of the add_*() API helper subrutines.
new_install() - Will just call ask_if_user_wants_to_install_fetchwarefile(), and
exist so that the user can run something as root if needed, and this will
prevent new() from running as root, because I don't want extensions having to
call drop_privs(). drop_privs() is to be invisible magic that just works as
needed :)
App::Fetchware::Fetchwarefile - will work pretty much like
App::Fetchware::Config works from config files, but for Fetchwarefiles instead.

So, there it is quite briefly. These API changes should make it nice and usable,
but keep it simple and testable. And since App::Fetchware has no infrastructure
in place for API versioning once its "done" it's *done*! It will never change,
except to fix bugs as needed.
Implemented and tested extension_name().

extension_name() is a "singleton". But not an actual Singleton object in java,
so I can still use global variables. Instead, it's just a subroutine that when
called the first time takes its first scalar, and saves and returns it back to
the caller. Then whenever this subroutine is called again, the same value is
returned back to the caller. This is implemented using a Perl 5.10 state
variable to avoid extra stupid parens to use a closure to fake the state
variable.

extension_name() is used to customize new()'s API subroutine's question text
that is printed to the user and error messages that the user might see, so that
the user sees 'App::FetchwareX::ExtensionName' instead of just the perhaps
confusing App::Fetchware.
Modified fetcwhare to use extension_name().

Originally I was going to use extension_name() everywhere it said 'Fetchware',
but I changed my mind. The use of 'Fetchware' does sorta mean
App::FetchwareX::ExtensionName already. So why change it? The downside is
App::FetchwareX::ExtensionName is gigantically long compared to just
'Fetchware', so it would screw up the the lines of the messages being less than
80 characters.

Instead, it's just used for App::Fetchware in a few error messages. I'm still
going to keep using it. It's self documenting, and it does make the few error
messages that use less confusing. So I think it's worth it, so I'm keeping it.
Deleted analyze_lookup_listing() and determine_mandatory_options().

They were crap leftovers from when I had no idea how I was going to implement
fetchware's new command's functionality, so I just created some functions with
some names with functionality to be added later. I wanted to analyze a lookup
listing to automatically choose most of the options if you're lucky, so I
created analyze_lookup_listing(), and keeping it now would just be confusing to
extension authors, because it does nothing but call
determine_mandatory_options() and determine_filter_option().

And all determine_mandatory_options() does is call add_mirrors() and
add_verification().

These are not complicated things, and if I had a less verbose commenty style of
Perl all of these subroutines would be tiny, so why bother combining them at
all?

It has no benefit, and is confusing and unneeded, and it screws up my later
designs, so they are gone.
Refactored get_{mirrors,verification,filter_option}.

I removed them calling append_options_to_fetchwarefile(), and instead have them
returning hashrefs, and then the caller or the soon to be written new_helper()
will do it for you.

I also renamed them all "get" instead of "add" or "determine". This is much
clearer, because now they return the filter or mirrors or whatever instead of
doing the appending to the Fetchwarefile for you.

This change was done to make them more flexible. Now extension authors can use
these subroutines, and instead of just appending the result to their
Fetchwarefile, they can do further analysis or use some configuration options,
but ignore others, or perhaps use the sames ones, but rename them.

All of these options may or may not be supported by new_helper(), which will
remove the tempation to just copy and paste all of the stupid repetitive calls
to append_options_to_fetchwarefile().
Factored out extension_name()'s guts to create singleton().

the way extension_name() works is also how fetchwarefile_header() and
fetchwarefile_options() will work. So, instead of copy and pasting some code
around, I created a cool singleton function factory in singleton().

I also copied and pasted singeton's test suite, and moved both over to Util. It
includes some additonal tests to ensure that the function factory correctly
creates the actual subroutine in the right package.

singleton() is limited on only working on scalars, so no hashes or arrays, but
references are scalars, so fetchwarefile_{header,options} will just require
hashrefs as arguments instead of regular hashes.
Implemented non-OO App:Fetchware::Fetchwarefile. Will go OO.

I've been struggling with having Fetchwarefile go OO or not. Unlike Config,
where because of the insane implementation of Fetchware's configuration
subroutines, and how they are implemented, Config is stuck with its crazy global
implementation. Furthermore, changing it now, would at best result in a per
module configuration scope, which is not much of an improvement over per
Fetchwarefile Config scope, which is what it's current configuration has. Also,
if I do change Config, I'll have to change much of the test suite to match the
new OO calling style, or create a backwards compatibility layer, or something
else horrible. Instead, Config stays non-OO, and very global.

Fetchwarefile, however, is going OO. It just makes sense. The only reason not to
go OO, is to leave it non-OO on purpose, because OO sucks. OO does suck, but it
can be great, or exactly what you want, and it's exactly what people expect.
App::Fetchware is staying its crazy old self, but App::Fetchware::Fetchwarefile
is going OO.

fetchware_config_options() and fetchware_header() vanish to be replaced by
new(), which is obviously a constructor. It takes all of the info that the other
regular subroutines used to take, but does it in one go. Fetchwarefile objects
will be immutable without any setters, because I don't need them, and if you
want to change them, just create a new Fetchwarefile object.

Then, fetchwarefile() will be replaced by generate(), and then they'll be a
config_option() setter, for adding options to you Fetchwarefile object.

And a __debug() to print debugging info out.

There will be no __set_fetchwarefile(), because now it's lexical instead of
global, so you can just create another Fetchwarefile object if you need to.

The next commit will change Fetchwarefile into OO. I just wanted to commit its
old non-oo interface in case I want to switch back to it for some reason.
Removed singleton(), because nothing uses it anymore.

singleton() was pretty cool, but kinda stupid, because using OO techniques
without actually using OO is both cool and stupid at the same time. It was cool,
but now it's no longer needed.

Bye bye, live long in git history.
Implemented and tested App::Fetchware::Fetchwarefile.

It's all done and tested, and surprisingly simple. It's actually simpler than
the previous non-OO code.

It's the only OO code in Fetchwarefile itself, and I managed to resist the
temptation to rewrite the rest of Fetchware as OO :)

Next, I'll convert cmd_new() to use Fetchwarefile.
Fixed sill Win32 file extension incompatibility.

I was foolishly using the static string 'perl' inside a subtest for
run_star_commands(). At first I though that maybe perl was not in the smoker's
PATH, but the output printed both the location of where perl was in the $^X
variable, and it also printed the PATH. But perl was in the smoker's PATH. Then
I figured since its called perl.exe instead of just perl on Windows that maybe
that was the problem especially since run_star_commands() and run_prog() both
use system() directly instead of something that uses that platforms version of
the shell. This may be the problem, because the shell is probably what allows
you to call commands on Windows without always using the .exe extension, and
using system uses whatever the Windows' equivelent version of directly executing
a program on Windows is. So, without the shell to add the .exe, my call of perl
fails.

I fixed this by simply using $^X instead of perl.

Also, this bug came to me in my Inbox from the fine folks at CPAN Testers. The
report is available at:
http://www.cpantesters.org/cpan/report/a6d26844-6c07-1014-9005-f13e6d8a8eb2

Note, this commit only fixes this simple bug. No investigation into the other
test failures has taken place yet.
Fixed flaw in previous check_syntax() and parse_fetchwarefile() impl.

parse_fetchwarefile() had a hard coded number of api subroutines in it set
to 9 in it, but now there are 11, and I'm about to add a 12. So, I updated
to use 'scalar keys %api_subs' instead of a hard coded value. Now, I only
have to add new API subs to %api_subs without worrying about the stupid
easily outdatable hard coded value.

There are also a few documentation fixes to check_syntax(). It's previous
documentation was total crap. I also removed the useless, and extremely
confusing $fetchwarefile argument from check_syntax(). It can no longer
check the actual $fetchwarefile text, but it can still test it via
config(), which was the whole point to begin with.
Ported cmd_new() to use App::Fetchware::Fetchwarefile.

cmd_new() is now using Fetchwarefile objects to represent Fetchwarefiles
inside cmd_new(). This also required updating cmd_new()'s test suite, and
removing some crufty old code from lookup() that was still calling
check_lookup_config().

Next up is moving cmd_new() to App::Fetchware as new() and new_install()
API subroutines.