On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar <ppisar(a)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
Is there a particular package you know about that I could check?
But that leads me to a question about -devel modules. RHEL delivers
-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.