On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar ppisar@redhat.com wrote:
On Tue, Mar 10, 2020 at 02:13:22PM -0700, Troy Dawson wrote:
We propose adding:
In EPEL 8 or later, it is permitted to have module streams which contain packages with alternate versions to those provided in RHEL. These packages may be newer, built with different options, or even older to serve compatibility needs. These MUST NOT be the default stream -- in every case, explicit user action must be required to opt in to these versions. If the RHEL package is in a RHEL module, then the EPEL module must have the same name as the RHEL module. Any exceptions to the module name must be approved by the EPEL Steering Committee.
That's a reasonable proposal.
I can only see a small ambiguity regarding build-only packages that are filtered out of the module. I believe the rule about the module names should not apply for these filtered packages.
If they are filtered out of the module, then end users cannot see and/or use them. If that is the case, they are fair game for EPEL, and I believe (but haven't checked) that packagers already should be able to request them. Is there a particular package you know about that I could check?
But that leads me to a question about -devel modules. RHEL delivers some -devel modules in a CRB repository. These -devel modules consists of the filtered packages. Is EPEL going to mimic these -devel modules, or not?
Can you give an example of a -devel package in CRB that is from a package that is filtered from a module? Most people have been complaining that there aren't enough -devel packages in CRB. If there are some in there that don't have an accessible package that corresponds to it, I think that's a bug on the RHEL side and we should let them know.
Troy