[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Wed, Mar 11, 2020 at 8:10 AM Petr Pisar 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 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-devel10.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@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Wed, Mar 11, 2020 at 06:52:12AM -0700, Troy Dawson wrote: > On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar wrote: > > > > 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. I thought so. > Is there a particular package you know about that I could check? > There can barely be any now because there are no modules in EPEL yet. And you cannot see any of the filtered packages in RHEL because they are not distributed to repositories (except the few -devel modules). > > 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-devel10.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. -- Petr signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: Reminder: EPEL Steering Committee meeting moved to Fridays
On Tue, Mar 10, 2020 at 12:47 PM Matthew Miller wrote: > > On Tue, Mar 10, 2020 at 09:09:11AM -0700, Troy Dawson wrote: > > Just a reminder that the EPEL Steering Committee meeting has been > > moved to Fridays at 2100 UTC. > > > > To find out when that is for you, do > > date -d "Fri 2100 UTC" > > > > A reminder should be sent out the day before. > > Hi Troy. Can you let me know if the modular-versions proposal is on an > upcoming agenda? > Yep, just put it on. We'll talk about it, and possibly vote on it, at this Fridays meeting. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
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. 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? -- Petr signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
