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 re-worded proposal. https://pagure.io/epel/issue/100 On Wed, Mar 11, 2020 at 3:03 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > On Wed, Mar 11, 2020 at 8:10 AM Petr Pisar <ppisar@xxxxxxxxxx> 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@xxxxxxxxxx> 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? > > > > RHEL-8.1.1: > > > > # dnf module list | grep -e -devel > > mariadb-devel 10.3 MariaDB Module > > virt-devel rhel Virtualization module > > virt-devel rhel Virtualization module > > > > 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 > permitted. > > Troy _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
