On Tue, May 15, 2018 at 03:06:43PM -0400, Stephen John Smoogen wrote:
Modules
[...]
EPIC-next
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
bases.
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.
EPIC
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"?)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader