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?


Attachment: 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: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to