Description of problem:
Can perl-BSD-Resource be branched for EPEL8?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
There are two AppStream modules for perl in RHEL8 right now. I'm not sure what the EPEL plan is for multi-perl....
EPEL does not support modules. Module support in EPEL is planned later (a tentative deadline was articulated as "EPEL-8.1").
Petr, do I read it right that any building of Perl modules in EPEL 8 is effectively on hold until the module support comes to EPEL? I've had requests for other modules, so would like to make sure I'm spreading the correct message.
The only information I have is <https://firstname.lastname@example.org/thread/HXFHAPXPG2FX4NHP2WDNE3J3JXE53LML/>. My interpretation is that it's not possible to build Modularity modules in EPEL 8.
And there is yet another issue: There are a few Perl packages modularized in RHEL. I'm sure people will want EPEL to provide their modularized rebuilds, so that users can switch to a different perl and still enjoy all the other Perl packages. A straightforward implementation is copying sources from CentOS to EPEL, wrapping them with a module and building the module in EPEL 8 while letting a stream expansion to build it for all perls. The downside is that the modular package would mask RHEL package. That was forbidden in EPEL 7 and I believe the same rule will apply to EPEL 8. There are few ways how to deal with it but none of them is simple. We need to clarify it with EPEL project owner and choose a right strategy in Perl/EPEL sig. I'd like to elaborate about it more in some list. Do you prefer Fedora's perl-devel or EPEL's epel-devel? I'd rather use perl-devel for discussing the strategy.
I'm not sure I understand the situation correctly. If I get EPEL 8 branch created today and just build the module, will it build (correctly) against the default module (5.26) and at least users of the default perl will be happy? Or will even this approach fail without the module support in EPEL? Or will it work but make things harder in the future when the module support gets to EPEL and we will want to do the rebuilds for the other modules?
I guess perl-devel is the reasonable venue.
(In reply to Jan Pazdziora from comment #4)
> If I get EPEL 8 branch created today and just build the module,
Here you mean a Perl module as non-modular RPM package.
> will it build (correctly) against the default module (5.26)
And here you mean a Modularity module.
> and at least users of the default perl will be happy?
Yes. That works. If you do not want to wait for EPEL supporting building modules, do that (i.e. build a normal RPM package).
In my ideal world, I'd love to be able to say "this package builds for these modules" and have some back end tooling that builds the package for all the various streams.
For example, this package perl-BSD-Resource could build for all the perl streams. This would let the package owner pick what streams they care about but maintain only the one source.... this is not possible today.
I'll reach out to Smoogen.....
FEDORA-EPEL-2019-adad709d1d has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-adad709d1d
perl-BSD-Resource-1.291.100-11.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-adad709d1d
perl-BSD-Resource-1.291.100-11.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report.