[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
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 wrote: > > 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 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: 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
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
Let's try to get this flushed out in time for our EPEL Steering Committee meeting this Friday. I think we've figured out most of the pitfalls that might happen. I believe this is what the discussion ended up with. The current guidelines [1] say: EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for. Thus packages from EPEL should never replace packages from the target base distribution - including those on the base distribution as well as layered products; kernel-modules further are not allowed, as they can disturb the base kernel easily. 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. Does this sound correct? I'd like to discuss/vote on this at this weeks committee meeting. Troy [1] - https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Packaging_Guidelines_and_Policies_for_EPEL ___ 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, Feb 25, 2020 at 5:05 PM Troy Dawson wrote: ... > While I agree that we should be very careful with this, I do not > believe it should be completely off the table. > I believe it should be permissible with the EPEL Steering Council's > blessing, but not otherwise. > Case in point is libssh2. > It was provided in the original RHEL 8.0 virt module, but not since > then. It's causing all sorts of grief, especially when people are > using both RHEL8 (where you see it) and CentOS8 (where do you don't). > There is a bugzilla ticket in with the team, but it looks like it's > going to take a while before a fix get's implemented. > My proposal is to create a libssh2 module, with a higher NEVR than in > that original RHEL8 module. > OK, I hadn't considered that aspect and I agree with you. Under *carefully controlled and approved circumstances*, we can permit updating a package from a different module. ___ 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, Feb 25, 2020 at 1:16 PM Stephen Gallagher wrote: > > On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller > wrote: > > > > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > > > Consider: > > > > > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > > > Can epel make a foo (non default) module that overrides it? > > > > > This is safe from a technical perspective and should be fully endorsed by > EPEL. > I agree > > > 2. foo rpm that is in a RHEL default module. > > > Can epel make a foo (non default) module that overrides it? > > > > > > 3. foo rpm that is in a RHEL non default module. > > > Can epel make a foo (non default) module that overrides it? > > > 2 and 3 are safe from a technical perspective with one major caveat: > they can only be replaced by an alternate stream of *the same module*. > This is because otherwise both RPMs will be visible to the package > manager and the behavior is complicated. I'm actually not sure which > way it will break; either both sets of RPMs will be visible to the > transaction and you'll end up with the highest NEVRA, regardless of > which one you intended to get; or both modules will suppress each > other and neither of their RPMs will be available. I think it's the > first case, but either way it should be avoided. > I recently talked with the software support group (I think that's their new name) asking about this, and it is the first. If two modules are both enabled, even if one is default and the other not, and the same package is in both, dnf will pick the highest NEVRA. While I agree that we should be very careful with this, I do not believe it should be completely off the table. I believe it should be permissible with the EPEL Steering Council's blessing, but not otherwise. Case in point is libssh2. It was provided in the original RHEL 8.0 virt module, but not since then. It's causing all sorts of grief, especially when people are using both RHEL8 (where you see it) and CentOS8 (where do you don't). There is a bugzilla ticket in with the team, but it looks like it's going to take a while before a fix get's implemented. My proposal is to create a libssh2 module, with a higher NEVR than in that original RHEL8 module. > This is also why we (Merlin and I) determined that the `epel-` prefix > was a non-starter; this case makes that too risky. > > If we want to find a way to highlight where a stream is coming from to > disambiguate EPEL streams from RHEL streams, I think we need to do > some UX work on `dnf module list` to display the source repo for each > available stream in a meaningful way. > > > Lastly, I think Petr Pisar is pretty much spot-on with his explanation > of the EPEL -> RHEL transition; we need to make sure that the > V(ersion) field in the module stream's NSVCA is higher for the new > RHEL version than it is in EPEL, similar to what we do with > non-modular packages today. In that case, DNF will just select the > RHEL version of the stream as an update to the EPEL version of the > stream and things should work out fine. The "gotcha" is those cases > where the EPEL maintainer doesn't know that a RHEL update is coming > and inadvertently updates to a higher version than RHEL ends up > delivering. As this case is basically identical to the non-modular RPM > case, the same mitigation strategies should work (either drop the > conflicting module contents from the repo or else release a higher > version in RHEL as an errata). > ___ > 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 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, Feb 25, 2020 at 3:57 PM Matthew Miller wrote: > > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > > Consider: > > > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > > Can epel make a foo (non default) module that overrides it? > > This is safe from a technical perspective and should be fully endorsed by EPEL. > > 2. foo rpm that is in a RHEL default module. > > Can epel make a foo (non default) module that overrides it? > > > > 3. foo rpm that is in a RHEL non default module. > > Can epel make a foo (non default) module that overrides it? 2 and 3 are safe from a technical perspective with one major caveat: they can only be replaced by an alternate stream of *the same module*. This is because otherwise both RPMs will be visible to the package manager and the behavior is complicated. I'm actually not sure which way it will break; either both sets of RPMs will be visible to the transaction and you'll end up with the highest NEVRA, regardless of which one you intended to get; or both modules will suppress each other and neither of their RPMs will be available. I think it's the first case, but either way it should be avoided. This is also why we (Merlin and I) determined that the `epel-` prefix was a non-starter; this case makes that too risky. If we want to find a way to highlight where a stream is coming from to disambiguate EPEL streams from RHEL streams, I think we need to do some UX work on `dnf module list` to display the source repo for each available stream in a meaningful way. Lastly, I think Petr Pisar is pretty much spot-on with his explanation of the EPEL -> RHEL transition; we need to make sure that the V(ersion) field in the module stream's NSVCA is higher for the new RHEL version than it is in EPEL, similar to what we do with non-modular packages today. In that case, DNF will just select the RHEL version of the stream as an update to the EPEL version of the stream and things should work out fine. The "gotcha" is those cases where the EPEL maintainer doesn't know that a RHEL update is coming and inadvertently updates to a higher version than RHEL ends up delivering. As this case is basically identical to the non-modular RPM case, the same mitigation strategies should work (either drop the conflicting module contents from the repo or else release a higher version in RHEL as an errata). ___ 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, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > Consider: > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > Can epel make a foo (non default) module that overrides it? > > 2. foo rpm that is in a RHEL default module. > Can epel make a foo (non default) module that overrides it? > > 3. foo rpm that is in a RHEL non default module. > Can epel make a foo (non default) module that overrides it? > > I think we all agree 3 is fine. > I think 2 could cause problems, but perhaps it would work. > I would think 1 would be fine also. These should all be fine. In the case of 2, it's just now another alternate non-default stream. It would only override if explicitly asked for. -- Matthew Miller Fedora Project Leader ___ 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, Feb 18, 2020 at 05:09:04PM +0100, Petr Pisar wrote: > So the bottom line is: Prefixed streams should provide a bullet proof > mitigation. Until DNF gains the ability to obsolete a stream, there will be > slight risk of creeping out-dated EPEL content into the installation. A prefix also makes it immediately obvious that a stream is EPEL and not product or supported. -- Matthew Miller Fedora Project Leader ___ 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, Feb 19, 2020 at 4:17 AM Pablo Sebastián Greco wrote: > > > On 18/2/20 21:06, Kevin Fenzi wrote: > > On Sat, Feb 15, 2020 at 05:17:01PM -0500, Matthew Miller wrote: > >> On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote: > >>> This is what I was trying to get to in the thread recently about > >>> libssh2. However it's still not entirely clear to me. > >>> > >>> Does this mean if there's a package foo that is a rhel package, but not > >>> in a module, that it can be overlapped with a foo package thats in a > >>> epel non default module? ie, does it only mean the modular case or does > >>> it mean any rpm? > >> I don't understand the last sentence. To the first question: yes, and that > >> non-default module package will only get installed if the module is > >> explicitly enabled. > > Consider: > > > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > > Can epel make a foo (non default) module that overrides it? > > > > 2. foo rpm that is in a RHEL default module. > > Can epel make a foo (non default) module that overrides it? > > > > 3. foo rpm that is in a RHEL non default module. > > Can epel make a foo (non default) module that overrides it? > > > > I think we all agree 3 is fine. > > I think 2 could cause problems, but perhaps it would work. > > I would think 1 would be fine also. > Kevin, I think 1 is a problem, because IIRC, if a package is part of a > module, its non-modular version is automatically hidden. Only if that module is default, or that module is enabled. Otherwise the regular, non-module, rpm is what you see. 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 18/2/20 21:06, Kevin Fenzi wrote: On Sat, Feb 15, 2020 at 05:17:01PM -0500, Matthew Miller wrote: On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote: This is what I was trying to get to in the thread recently about libssh2. However it's still not entirely clear to me. Does this mean if there's a package foo that is a rhel package, but not in a module, that it can be overlapped with a foo package thats in a epel non default module? ie, does it only mean the modular case or does it mean any rpm? I don't understand the last sentence. To the first question: yes, and that non-default module package will only get installed if the module is explicitly enabled. Consider: 1. foo rpm that is in the RHEL baseos. It's not in any module. Can epel make a foo (non default) module that overrides it? 2. foo rpm that is in a RHEL default module. Can epel make a foo (non default) module that overrides it? 3. foo rpm that is in a RHEL non default module. Can epel make a foo (non default) module that overrides it? I think we all agree 3 is fine. I think 2 could cause problems, but perhaps it would work. I would think 1 would be fine also. Kevin, I think 1 is a problem, because IIRC, if a package is part of a module, its non-modular version is automatically hidden. kevin Pablo. ___ 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 Sat, Feb 15, 2020 at 05:17:01PM -0500, Matthew Miller wrote: > On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote: > > This is what I was trying to get to in the thread recently about > > libssh2. However it's still not entirely clear to me. > > > > Does this mean if there's a package foo that is a rhel package, but not > > in a module, that it can be overlapped with a foo package thats in a > > epel non default module? ie, does it only mean the modular case or does > > it mean any rpm? > > I don't understand the last sentence. To the first question: yes, and that > non-default module package will only get installed if the module is > explicitly enabled. Consider: 1. foo rpm that is in the RHEL baseos. It's not in any module. Can epel make a foo (non default) module that overrides it? 2. foo rpm that is in a RHEL default module. Can epel make a foo (non default) module that overrides it? 3. foo rpm that is in a RHEL non default module. Can epel make a foo (non default) module that overrides it? I think we all agree 3 is fine. I think 2 could cause problems, but perhaps it would work. I would think 1 would be fine also. kevin 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: Proposed official change to EPEL guidelines: modules and RHEL
On Thu, Feb 13, 2020 at 07:54:24AM -0500, Matthew Miller wrote: > I've been saying this for a while as if it's fact, but of course it's not > actually fact until approved, so I'm puting this to the EPEL team to > hopefully do so. > > The current guidelines * say: > >EPEL packages should only enhance and never disturb the Enterprise Linux >distributions they were built for. Thus packages from EPEL should never >replace packages from the target base distribution - including those on the >base distribution as well as layered products; kernel-modules further are >not allowed, as they can disturb the base kernel easily. > > With modularity in EPEL 8, we have the opportunity to allow more flexibility > while preserving the primary goal of not disturbing the base distribution. > Therefore, I 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. > > > (Note that the base package _does not_ have to be part of a module for this > to work.) > > What do you think? > > Nicely and clearly stated. -- 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: Proposed official change to EPEL guidelines: modules and RHEL
On Sat, Feb 15, 2020 at 07:15:55PM -0700, Ken Dreyer wrote: > On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller > wrote: > > > > 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. > > Is there any chance that a module in EPEL 8 will be named identically > to a module in RHEL 8? If that happens, what is the process to choose > between RHEL's module and EPEL's module? > > This is not entirely hypothetical :) We face this situation if we > consider putting Ceph into a module in RHEL 8 and a module in EPEL 8. > This was discussed in fall last year without any conclusion. There was a proposal force all EPEL streams having a prefix (e.g "epel-") to prevent from clashes. In my opinion the situation with same named streams is similar to situation with same named packages. If RHEL is going to add new package that already exists in EPEL, RHEL uses an higher NEVRA of the package and EPEL will remove the package later. You can do the same with module streams. Module streams also have versions. The version is based on a RHEL version and a time when the module was built. That itself ensures incrasing stream versions. But that's not enough to ensure an upgrade path on package level. The reason is that if a stream is enabled, all of its versions that exist in the repositories are inspected and all of their packages are made available. That means that if a RHEL repository contains multiple versions of a stream, then DNF will see all the historical packages. That would apply to EPEL repositories too. A solution is that RHEL will ensurure that each package of the stream will have an higher NEVRA than the EPEL one. See it's the same as with non-modular packages. The only difference is that you need account more packages than the usual one. The only remaining issue is what to do with packages that existed in EPEL repository but were not added into RHEL repository. Well, technically it does not matter that there is an old package. When it would matter is when RHEL decided to add the package as non-modular one and at the same time the RHEL stream would be a default one. Then DNF would prefer the old modular package because the stream is default now. EPEL could solve it by removing the old module from its repositories. But what if the the user had already have the package from EPEL stream installed. In that case, I believe, I'm not sure how exactly DNF implements it, DNF would kept considering the package as modular because DNF cashes modular metadata of installed packages for the case when a repository becomes unavailable. A long term solution is DNF to support obsoleting modular packages by non-modular packages or handling end-of-life streams better. As far as I know this has not yet been designed, neither implemented. So the bottom line is: Prefixed streams should provide a bullet proof mitigation. Until DNF gains the ability to obsolete a stream, there will be slight risk of creeping out-dated EPEL content into the installation. -- 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: Proposed official change to EPEL guidelines: modules and RHEL
On Sat, Feb 15, 2020 at 05:15:56PM -0500, Matthew Miller wrote: > On Fri, Feb 14, 2020 at 05:14:31PM -0600, Chris Adams wrote: > > Unless... does RHEL have modules that replace base packages? I admit, I > > haven't fully got my head wrapped around all the effects of modularity. > > I'm not sure if RHEL has any such modules, but it is functionally possible. > There is a perl-DBI module that provides a perl-DBI package that replaces a base perl-DBI package. There are more modules like that. It's an alternative approach to the stub streams discussed in this thread. -- 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: Proposed official change to EPEL guidelines: modules and RHEL
On Tue, 18 Feb 2020 at 10:34, Petr Pisar wrote:
> On Sat, Feb 15, 2020 at 05:12:29PM -0500, Matthew Miller wrote:
> > On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> > > From my also little understanding of modularity, this is so you can
> > > reinstall base perl packages. In some ways ( I am glossing over things
> > > here), modular rpms always beat bare rpms because a module can put in
> rules
> > > to say 'you can install this package but it does not work with these
> rpms
> > > so they need to be removed'. So I think any modules we write which
> would
> > > over-ride non-modular packages, we would also need to write a 'get me
> back
> > > my f'ing defaults' module which stubs in a similar way the perl and
> some
> > > other modules do.
> >
> > No, this is not the case. If the module isn't enabled its packages will
> just
> > be ignored. It's only if you enable the module that you get the RPMs from
> > that module.
> >
> Exactly. If you want to revert back to a non-modular package, just reset
> the module
> (e.g. "dnf module --reset perl"). That will disappear modular packages from
> from the repository and make the non-modular packages available again.
>
> Here is a simple explanation what enabling a module stream means: If you
> enable a module stream ("dnf module --enable perl:5.24"), DNF obtains a
> list
> of binary packages belonging to that stream (e.g. perl-interpreter-5.24.4),
> makes them available (to dnf install, repoquery etc.) and at the same time
> makes the same-named packages (either non-modular or from a different
> stream
> of the same module) unavailable (e.g. perl-interpreter-5.26.3 disappears).
> When you reset the module, you effectively reverts it. This process of
> making
> the packages avaiable/unavailable DNF calles a modular filtering.
>
> The purpose of the stub (without packages) perl:5.26 stream is different
> and
> mostly unrelated . It is there to enable having modules above the perl
> module
> in an easy way. Otherwise the layered module maintainers would have take
> care
> whether they target Perl 5.26 that is non modular or Perl 5.24 that is
> modular. The dummy perl:5.26 stream provides a unified modular interface to
> other modules.
>
>
OK I was clearly confused and not correctly remembering why you had said
perl:5.26 was there. I apologize for the misinformation here.
> EPEL packagers that want to provide an alternative stream to non-modular
> packages are not required to provide the dummy streams. Although the dummy
> streams can become handy later for the very same reason. The dummy streams
> can
> added later when needed and when found useful.
>
> -- Petr
> ___
> 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
>
--
Stephen J Smoogen.
___
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 Sat, Feb 15, 2020 at 05:12:29PM -0500, Matthew Miller wrote:
> On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> > From my also little understanding of modularity, this is so you can
> > reinstall base perl packages. In some ways ( I am glossing over things
> > here), modular rpms always beat bare rpms because a module can put in rules
> > to say 'you can install this package but it does not work with these rpms
> > so they need to be removed'. So I think any modules we write which would
> > over-ride non-modular packages, we would also need to write a 'get me back
> > my f'ing defaults' module which stubs in a similar way the perl and some
> > other modules do.
>
> No, this is not the case. If the module isn't enabled its packages will just
> be ignored. It's only if you enable the module that you get the RPMs from
> that module.
>
Exactly. If you want to revert back to a non-modular package, just reset the
module
(e.g. "dnf module --reset perl"). That will disappear modular packages from
from the repository and make the non-modular packages available again.
Here is a simple explanation what enabling a module stream means: If you
enable a module stream ("dnf module --enable perl:5.24"), DNF obtains a list
of binary packages belonging to that stream (e.g. perl-interpreter-5.24.4),
makes them available (to dnf install, repoquery etc.) and at the same time
makes the same-named packages (either non-modular or from a different stream
of the same module) unavailable (e.g. perl-interpreter-5.26.3 disappears).
When you reset the module, you effectively reverts it. This process of making
the packages avaiable/unavailable DNF calles a modular filtering.
The purpose of the stub (without packages) perl:5.26 stream is different and
mostly unrelated . It is there to enable having modules above the perl module
in an easy way. Otherwise the layered module maintainers would have take care
whether they target Perl 5.26 that is non modular or Perl 5.24 that is
modular. The dummy perl:5.26 stream provides a unified modular interface to
other modules.
EPEL packagers that want to provide an alternative stream to non-modular
packages are not required to provide the dummy streams. Although the dummy
streams can become handy later for the very same reason. The dummy streams can
added later when needed and when found useful.
-- 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: Proposed official change to EPEL guidelines: modules and RHEL
On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller wrote: > > 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. Is there any chance that a module in EPEL 8 will be named identically to a module in RHEL 8? If that happens, what is the process to choose between RHEL's module and EPEL's module? This is not entirely hypothetical :) We face this situation if we consider putting Ceph into a module in RHEL 8 and a module in EPEL 8. - Ken ___ 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 Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote: > This is what I was trying to get to in the thread recently about > libssh2. However it's still not entirely clear to me. > > Does this mean if there's a package foo that is a rhel package, but not > in a module, that it can be overlapped with a foo package thats in a > epel non default module? ie, does it only mean the modular case or does > it mean any rpm? I don't understand the last sentence. To the first question: yes, and that non-default module package will only get installed if the module is explicitly enabled. -- Matthew Miller Fedora Project Leader ___ 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 Fri, Feb 14, 2020 at 05:14:31PM -0600, Chris Adams wrote: > As a consumer of EPEL, I'd rather nothing in the base RHEL (or really > CentOS in my case) ever get replaced, up or downgrade, by something in > EPEL. Nothing in EPEL would by default, but you could explicitly chose to. This would be like enabling a Copr or other repo which happens to override, but more integrated. > Unless... does RHEL have modules that replace base packages? I admit, I > haven't fully got my head wrapped around all the effects of modularity. I'm not sure if RHEL has any such modules, but it is functionally possible. -- Matthew Miller Fedora Project Leader ___ 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 Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote: > From my also little understanding of modularity, this is so you can > reinstall base perl packages. In some ways ( I am glossing over things > here), modular rpms always beat bare rpms because a module can put in rules > to say 'you can install this package but it does not work with these rpms > so they need to be removed'. So I think any modules we write which would > over-ride non-modular packages, we would also need to write a 'get me back > my f'ing defaults' module which stubs in a similar way the perl and some > other modules do. No, this is not the case. If the module isn't enabled its packages will just be ignored. It's only if you enable the module that you get the RPMs from that module. -- Matthew Miller Fedora Project Leader ___ 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
Once upon a time, Stephen John Smoogen said: > From my also little understanding of modularity, this is so you can > reinstall base perl packages. In some ways ( I am glossing over things > here), modular rpms always beat bare rpms because a module can put in rules > to say 'you can install this package but it does not work with these rpms > so they need to be removed'. So I think any modules we write which would > over-ride non-modular packages, we would also need to write a 'get me back > my f'ing defaults' module which stubs in a similar way the perl and some > other modules do. Thanks for the explanation - I agree with you, that if RHEL doesn't already have a base module (like the perl example you listed), then any EPEL module that overrides a base RHEL package needs to also proved the module to get back to RHEL. I get the desire/need for modularity... it just seems so complicated. As a really small-time packager, modularity has been over my head (but the few packages I have don't need it, so I also haven't tried super hard). -- Chris Adams ___ 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 Fri, 14 Feb 2020 at 18:14, Chris Adams wrote: > Once upon a time, Kevin Fenzi said: > > Does this mean if there's a package foo that is a rhel package, but not > > in a module, that it can be overlapped with a foo package thats in a > > epel non default module? ie, does it only mean the modular case or does > > it mean any rpm? > > As a consumer of EPEL, I'd rather nothing in the base RHEL (or really > CentOS in my case) ever get replaced, up or downgrade, by something in > EPEL. > > Unless... does RHEL have modules that replace base packages? I admit, I > haven't fully got my head wrapped around all the effects of modularity. > > So the way that RHEL did this in el8.0 seems to have been to make a pseudo module perl 5.24 common [d], minimal Practical Extraction and Report Language perl 5.26 [d] common [d], minimal Practical Extraction and Report Language The perl-5.24 is a real module built in the modularity system. If you do a yum module info perl, it gives you every package in it. The perl-5.26 module is a 'stub' where it mentions mainly masks in the base packages like perl-interpreter-5.26.3-416.el8.x86_64 . So you can replace all the core perl packages with a module.. >From my also little understanding of modularity, this is so you can reinstall base perl packages. In some ways ( I am glossing over things here), modular rpms always beat bare rpms because a module can put in rules to say 'you can install this package but it does not work with these rpms so they need to be removed'. So I think any modules we write which would over-ride non-modular packages, we would also need to write a 'get me back my f'ing defaults' module which stubs in a similar way the perl and some other modules do. -- Stephen J Smoogen. ___ 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
Once upon a time, Kevin Fenzi said: > Does this mean if there's a package foo that is a rhel package, but not > in a module, that it can be overlapped with a foo package thats in a > epel non default module? ie, does it only mean the modular case or does > it mean any rpm? As a consumer of EPEL, I'd rather nothing in the base RHEL (or really CentOS in my case) ever get replaced, up or downgrade, by something in EPEL. Unless... does RHEL have modules that replace base packages? I admit, I haven't fully got my head wrapped around all the effects of modularity. -- Chris Adams ___ 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 Thu, Feb 13, 2020 at 07:54:24AM -0500, Matthew Miller wrote: > I've been saying this for a while as if it's fact, but of course it's not > actually fact until approved, so I'm puting this to the EPEL team to > hopefully do so. > > The current guidelines * say: > >EPEL packages should only enhance and never disturb the Enterprise Linux >distributions they were built for. Thus packages from EPEL should never >replace packages from the target base distribution - including those on the >base distribution as well as layered products; kernel-modules further are >not allowed, as they can disturb the base kernel easily. > > With modularity in EPEL 8, we have the opportunity to allow more flexibility > while preserving the primary goal of not disturbing the base distribution. > Therefore, I 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. > > > (Note that the base package _does not_ have to be part of a module for this > to work.) > > What do you think? This is what I was trying to get to in the thread recently about libssh2. However it's still not entirely clear to me. Does this mean if there's a package foo that is a rhel package, but not in a module, that it can be overlapped with a foo package thats in a epel non default module? ie, does it only mean the modular case or does it mean any rpm? kevin 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: Proposed official change to EPEL guidelines: modules and RHEL
On 2/13/20 6:54 AM, Matthew Miller wrote: I've been saying this for a while as if it's fact, but of course it's not actually fact until approved, so I'm puting this to the EPEL team to hopefully do so. The current guidelines * say: EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for. Thus packages from EPEL should never replace packages from the target base distribution - including those on the base distribution as well as layered products; kernel-modules further are not allowed, as they can disturb the base kernel easily. With modularity in EPEL 8, we have the opportunity to allow more flexibility while preserving the primary goal of not disturbing the base distribution. Therefore, I 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. (Note that the base package _does not_ have to be part of a module for this to work.) What do you think? I like it, but perhaps it is worth adding a note that EPEL8 packages must not include an 'Obsoletes' that targets packages shipped in RHEL itself. -- Pat Riehecky Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org ___ 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 Thu, Feb 13, 2020 at 4:54 AM Matthew Miller wrote: > > I've been saying this for a while as if it's fact, but of course it's not > actually fact until approved, so I'm puting this to the EPEL team to > hopefully do so. > > The current guidelines * say: > >EPEL packages should only enhance and never disturb the Enterprise Linux >distributions they were built for. Thus packages from EPEL should never >replace packages from the target base distribution - including those on the >base distribution as well as layered products; kernel-modules further are >not allowed, as they can disturb the base kernel easily. > > With modularity in EPEL 8, we have the opportunity to allow more flexibility > while preserving the primary goal of not disturbing the base distribution. > Therefore, I 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. > > > (Note that the base package _does not_ have to be part of a module for this > to work.) > > What do you think? > > > * > https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Packaging_Guidelines_and_Policies_for_EPEL Good idea. I think you worded it very well. 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
