On Tue, May 15, 2018 at 03:06:43PM -0400, Stephen John Smoogen wrote:
> The tooling for modules can match how Fedora approaches it. This
> means that rules for module inclusion will be similar to package
> inclusion. EPIC-next modules must not replace/conflict with CentOS
> modules. They may use their own namespace to offer newer versions
> than what is offered and those modules may be removed in the next
> minor release if CentOS offers them then.
I think we should do this part differently. Each Fedora module has its
own lifespan, separate from that of the base OS. It automatically gets
built across all currently-supported base OSes. That way, I can
maintain, say, "calc-2.x" in just one stream (where stream = git
branch), and it automatically gets built everywhere. Rather than having
EPIC modules be entirely separate, I'd like to just include them in
this: by default, build all modules against both the Fedora _and_ EL
This has a further implication: these modules _may_ replace or conflict
with CentOS (and possibly RHEL) modules. But you'd have to opt-in to
those streams explicitly to do so. With non-modular Yum/DNF, having some
packages update base software would be horrific because enabling the
repo and running `yum update` would do who-knows-what. But with
modules, that's not a problem.
> Extra Packages Inter Community.
Extra Packages for Impassioned Community?
Extra Packages Included by Community?
Extra Packages Introduced by Community?
Extra Packages Including Community?
Extra Packages for Innnnnterprise Community? (Or "EPEC"?)
Fedora Project Leader
epel-devel mailing list -- email@example.com
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines