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.