Description of problem: perl-Compress-Raw-Zlib-2.023-116.fc13 showed up in updates to F13 with a build date from "Fri 23 Jul 2010". The problem is that F13 came with perl-Compress-Raw-Zlib-2.027-1.fc13 with a build date "Tue 11 May 2010". Thus a version of an "old" package is higher and this update does not apply in an absence of a bumped up epoch. What was really an intention here? Version-Release number of selected component (if applicable): perl-Compress-Raw-Zlib-2.023-116.fc13
Checking closer such "non-update" was issued for F12 as well but there it was built on Fri 09 Jul 2010 as perl-Compress-Raw-Zlib-2.023-90.fc12 while perl-Compress-Raw-Zlib-2.027-1.fc12 is from Tue 11 May 2010. I did not look over other possible distro candidates.
That was intentional. perl-Compress-Raw-Zlib module lives in perl core, where is older version. Updates of modules are done in separate cvs. Recommendation for updates of core modules: https://fedoraproject.org/wiki/Perl/updates#Updates_of_Perl_core_modules
(In reply to comment #2) > That was intentional. If this was intentional then this is a pure waste of time. 'yum update' will not replace version 2.027-1 with 2.023-<whatever> unless epoch tag is suitably set. What is worse if some critical fixes would show up in 2.023 series then, contrary to appearances and changelogs, they will never show up in an installed software. Even installing F13 from scratch will be of no help here as perl-Compress-Raw-Zlib-2.027-1.fc13 shows up in a release so it will not go from repositories.
Core perl modules in Fedora now come from one of two sources: 1. as a subpackage of the main perl module, which will generally be the version bundled with the upstream perl distribution 2. as a separately maintained (standalone) package based on an upstream release from CPAN In this case, the Fedora perl package includes version 2.023 of perl-Compress-Raw-Zlib and the standalone package is version 2.027. The point of splitting out these packages into their own packages is so that they can be updated more easily without having to respin the whole perl package for every module update, requiring 100 MB or so download of unchanged perl code for a few KB of module update. So when an updated perl version is issued to fix an actual perl bug, it may contain some perl module subpackages that are older than the ones already issued. This doesn't matter - the standalone package is the one that's being kept up to date and the one that ends up on users' systems. That's what's intended. Now it might be argued that the main perl package shouldn't generate subpackages for modules that are maintained separately in Fedora. I can see the logic in that argument. But it wouldn't make any difference to the end users - they get the latest (highest numbered, rather than chronologically built) version whether it comes from the main perl package or the standalone package, and that's what's intended.
Thank you Paul for great explanation. Michael, do you have any other questions.
(In reply to comment #5) > Thank you Paul for great explanation. > > Michael, do you have any other questions. As long as everybody involved is fully aware what is happening then I think this is OK. OTOH I know that situations "(nearly) the same thing in two different independent places" on a long range have a nasty habit of biting back one way or another. Myself I would try hard not to get into something like that.