Description of problem: Many of the "Provides:" entries of the perl-Encode package include version numbers which do not actually exist. This is caused by incorrectly trimming leading zeros. Version-Release number of selected component (if applicable): All versions & releases of perl-Encode in Fedora/CentOS/RedHat (I think) How reproducible: Easily Steps to Reproduce: 1. Visit https://fedora.pkgs.org/28/fedora-x86_64/perl-Encode-2.97-3.fc28.x86_64.rpm.html 2. Scroll down to "Provides" section, "perl(Encode::Byte) = 2.4" 3. Visit https://metacpan.org/pod/Encode::Byte 4. Left side of page, "Module version: 2.04" Actual results: 2.4 Expected results: 2.04 Additional info: The same problem applies to most or all of the other Provides modules after Encode::Byte which have a leading 0 after the decimal, such as Encode::CJKConstants & Encode::Config & Encode::EBCDIC etc etc. Modules which do not have a leading 0 do not seem to be affected, such as Encode::CN::HZ 2.10 & MIME::Header 2.28 etc. Looking at the perl-Encode specfile, I am not exactly sure how to fix this, because the "Provides:" entries seem to be auto-generated... https://src.fedoraproject.org/rpms/perl-Encode/blob/master/f/perl-Encode.spec It is incorrect to trim leading zeros, because it does not allow for the proper conversion of numeric Perl version "2.40" which can easily be rounded to "2.4" by Perl's numeric processing. This also breaks automatic versioning and packaging systems. The Fedora Versioning Guidelines clearly states: "Don't trim leading zeroes." https://fedoraproject.org/wiki/Packaging:Versioning
I'll answer in a reverse order: The guidelines are about RPM package versions and how they relate to upstream release versions. It has nothing to do with Perl module versioning that is a Perl specific matter. RPM versions 2.04 and 2.4 are equivalent. RPM versions comparator ignores leading zeros: $ rpmdev-vercmp 2.04 2.4 2.04 == 2.4 The Encode::Byte $VERSION is defined in the module file like this: our $VERSION = do { my @r = ( q$Revision: 2.4 $ =~ /\d+/g ); sprintf "%d." . "%02d" x $#r, @r }; The RPM module versions are generated by parsing the line, while CPAN evaluates the line. Evaluating a Perl code is expensive and insecure. That's why RPM dependency generator does report 2.4 while CPAN reports 2.04. As you know RPM and Perl versions are incompatible. Because RPM versions are used by RPM, they must obey RPM arithmetic. I have prepared an automatic normalization of these generated RPM versions so that they provide correct Perl and RPM values at the same time but that change cannot be applied alone because the non-normalized version values are used through out hundreds of RPM packages. These hundreds of packages would have to be adjusted. And last time I ask Perl packagers about introducing this change, they disapproved it. Hence the RPM versions are good only for RPM now. If you want to use Perl module versions for Perl purposes, please use data from META.json or ask CPAN database instead. This is not currently supported feature. Because "2.04" and "2.4" are RPM-equivalent, I'm not going to work around this RPM dependency generator deficiency in the perl-Encode package. It would make it less legible and harder to maintain and that all without any benefit to RPM package ecosystem. Instead I will open a request fir RPM dependency generator change the version retrieval, but don't have high hopes. This is a very conservative part of packaging.
I opened bug #1629642 for perl-generators.