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.