The discussion on this at the EPEL Steering Committee brought up
another point. Although we agreed on the point, we didn't feel we had
enough time to re-word things.
So, we have shifted off voting until next week.
I have also shifted the conversation to an EPEL issue with the
On Wed, Mar 11, 2020 at 3:03 PM Troy Dawson <tdawson(a)redhat.com> wrote:
On Wed, Mar 11, 2020 at 8:10 AM Petr Pisar <ppisar(a)redhat.com> wrote:
> On Wed, Mar 11, 2020 at 06:52:12AM -0700, Troy Dawson wrote:
> > On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar <ppisar(a)redhat.com> wrote:
> > >
> > > 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?
> # dnf module list | grep -e -devel
> mariadb-devel 10.3 MariaDB
> virt-devel rhel
> virt-devel rhel
> E.g. virt-devel:rhel:8010020190916153839 contains
> qemu-kvm-tests-15:2.12.0-88.module+el8.1.0+4233+bc44be3f.x86_64 package.
> RHEL-8.2 Beta brings python38-devel:3.8 module.
Thank you for the examples. I hadn't thought of them. I am going to
paste what I proposed, so I can see it right below the examples to see
if it still works or not with them.
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.
With all of your examples, the main package is in a RHEL module. As
such, the main package would need to be in an EPEL module if it is in
EPEL, and would have to follow the EPEL module rules. So, I think
they should be ok to be in an EPEL module.
A) For the main package (ex: mariadb) that is in a RHEL module, we
have stated that we can have an EPEL module, but it must not be
default, and it must have the same name as the mariadb module.
B) For the -devel packages (ex: mariadb-devel), it would need to be in
a module, because we would be having an alternative version of a
package provided by RHEL. And it would be in a module, in our
examples case, the mariadb module.
So, I believe the proposal above, covers this case. If someone created
a module, such as mariadb, that has a -devel in CRB, it would be