On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
>
> On 8/23/19 10:56 AM, Stephen Gallagher wrote:
...
> > For default profiles, we have some options as well:
> >
> > Option 1: We disallow setting default profiles for EPEL streams. Pros:
> > no risk of conflict with RHEL, should they now or in the future
> > provide defaults for some streams of this module. Cons: `yum module
> > install foo[:bar]` would not work (they would need to do `yum module
> > install foo[:bar]/profilename`) and would likely irritate users.
> >
> > Option 2: We allow setting default profiles for EPEL streams. We take
> > advantage of the defaults merging logic and ensure that if we need to
> > supplement RHEL AppStream's defaults content, we must ship a
> > modulemd-defaults document of the same `data.version`. This will allow
> > them to be merged cleanly. Pros: Optimum user experience (they get the
> > default profiles installed when they use the simplified install
> > command). Cons: We need to constantly monitor each RHEL AppStream
> > release and ensure that we aren't ever overriding (or being overridden
> > by) RHEL.
> >
> >
> > I think Option 2 is the better choice here (fewer angry users is a
> > good thing), but I worry a bit about the maintenance burden of keeping
> > track of the `data.version` values and ensuring they stay in sync. I
> > think we can probably automate a good deal of this, though.
>
>
> Yeah, I would like to do 2 also if we can manage to make it mostly
> automated.
>
So, after discussing things at today's Modularity WG meeting, we've
decided to make a breaking change to libmodulemd's merging logic to
solve this much more cleanly. Full details are in
https://github.com/fedora-modularity/libmodulemd/issues/368
With that change in place, Option 2 becomes the obvious correct
choice, since we won't have to worry about the monitoring of the
`data.version` values.
That seems reasonable. Thank you.
-- Petr