On Tue, Sep 24, 2019 at 08:44:56PM -0400, Stephen Gallagher wrote: > On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi <kevin@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
