On Thu, 13 Jun 2019 23:09:58 +0200, Patrick Dupre wrote:
Maybe, however, some perl packages require packages with a version number higher than a certain value. Thus, if the Provides/Requires instructions are not set properly, all the packages requiring other packages fail, either at the build or installation step.
That doesn't make any sense at all.
The Provides/Requires dependencies are set automatically at build-time. One package _provides_ exactly what is found within in. Another package _requires_ exactly what it uses in its code. These automatic dependencies are correct at build-time, if and only if none of the providing packages is taken away or replaced with something incompatible (such as failing to satisfy >= requirements due to API changes or runtime behaviour changes).
If a Perl Module included in an RPM package is version X.Y, the package must not be used, if a package requires a version higher than X.Y. The package metadata must only provide exactly the version of the Perl Module that is included. That is why perl-generators is used to create these dependencies at build-time. If a newer version of the Perl Module is needed, an update to the package collection may be needed.
If you hack a spec file with manually added "Provides:" for a higher version, you are working against the entire system of package dependencies.
In my opinion, all the perl packages need to be checked to go through the distribution without requiring to use capnspec by the final user.
That is entirely unrelated to this mailing-list thread. It could be that there are perl-* RPM packages included in Fedora's package collection, which are missing the perl-generators build requirement and which are missing "perl(A::B) = version" provides. If that is the case, file a bug report. Or step up as co-maintainer, if you depend on such packages.