We have a major problem with both efs-perl and efs-deploy: we're using Sort::Versions (either the module, or our own versioncmp sub ripped from the module), which gets things WRONG for a lot of real world and important use cases.
For example, Sort::Versions will consider DateTime-0.1401 to be a newer release than DateTime-0.70. The latter is the latest release. This is because it compares 1 to 1, and then 1401 to 70, and of course 1401 > 70. But, that's wrong.... The best single document I've found on perl versions is this one: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring Reading that again, I think we can use the following approach to fix this mistake: use version->parse to interpret version strings, and then compare the objects. We will need to eval both values being compared, and if we don't get version objects for both, then we will fall back on using the Sort::Version code to make the comparison. The only problem I can see is that in EFS 2 land, the oldest perl is 5.8.8, and version.pm was added to the core in 5.10. For efs-deploy, this is not an issue -- that code can simply depend on the CPAN module. For efs-perl, however, we can NOT depend on anything other than core modules, so we have to come up with a workaround. I think it's fair to say that no new EFS domains will be created going forward that support perl5.8. Therefore, I think we can cheat in EFS 2 land. You already have perl5/version installed, so it might be reasonable to have EFS-Perl depend on the pre-installed version CPAN module to accomplish this. The question is HOW. For now, I'm going to punt on this, and when/if EFS 2 catches up with the leading edge of all this work I've done, we can work together to implement a solution. Look for a patch that implements this later today. Right now, I'm blocking on this....
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
