tokuhirom/OrePAN2 — pull request #32 by oalders (2014-11-27 23:16:31+00:00)
Title: undef module versions point to the the last modified archive which provides them

If two packages have the same version, prefer the one which is last in.

This prevents the following scenario, which occurs if OrePAN2-0.32 is added after OrePAN2-0.31:

OrePAN2 0.32 D/DU/DUMMY/OrePAN2-0.32.tar.gz
OrePAN2::CLI::Indexer undef D/DU/DUMMY/OrePAN2-0.31.tar.gz
OrePAN2::CLI::Inject undef D/DU/DUMMY/OrePAN2-0.31.tar.gz
OrePAN2::Index undef D/DU/DUMMY/OrePAN2-0.31.tar.gz
OrePAN2::Indexer undef D/DU/DUMMY/OrePAN2-0.31.tar.gz

I bumped some versions in this branch as part of debugging, but I think it's probably a good idea to have later versions of these modules. There were two problems here.

1) As detailed above, if you have a distribution containing modules with unchanging version numbers, the distribution which was added to the index first would win. So, when you have modules with `undef` versions it's just a matter of which module gets into the index first and you may or may not get your desired results.

2) Related to this is that fact that when the darkpan is scanned, files don't come back in exactly the same order for different versions of Perl. So, you have this first-in scenario, but you also can't say with confidence which file will be in first.

My solution here is to

a) prefer modules with the same version that are the newest (by modification time)
b) sort the archives by modification time so that we add the oldest files first, allowing modules from later uploads which don't have version bumps to take precedence over the older modules.

The end result _should_ be that the above problem is solved. This still doesn't solve the problem of modules moving from one distribution to another, but in those cases I would hope that the versions get bumped. So, while it may still have some rough edges, I _think_ that it has less rough edges than before I started with it. :)