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
>
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
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
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
On 15. 02. 20 0:01, Kevin Fenzi wrote:
Nope. We don't ever sync or use betas... once it's released it should be
possible to use it however.
To clarify (I forgot to say that) I meant to do it after the actual release, not
during beta.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
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
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
