On Wed, Oct 9, 2019 at 6:32 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Wed, Oct 9, 2019, 12:29 Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: >> >> On 04. 10. 19 21:31, Miro Hrončok wrote: >> > On 04. 10. 19 16:57, Stephen Gallagher wrote: >> >> Right now, there are two conflicting requirements in Fedora Modularity >> >> that we need to resolve. >> >> >> >> 1. Once a user has selected a stream, updates should follow that >> >> stream and not introduce incompatiblities. Selected streams should not >> >> be changed without direct action from the user. >> >> 2. So far as possible, Modularity should be invisible to those who >> >> don't specifically need it. This means being able to set default >> >> streams so that `yum install package` works for module-provided >> >> content. >> >> >> >> Where this becomes an issue is at system-upgrade time (moving from >> >> Fedora 30->31 or continuously tracking Rawhide). Because of >> >> requirement 1, we cannot automatically move users between streams, but >> >> in the case of release upgrades we often want to move to a new default >> >> for the distribution. >> > >> > >> > Wouldn't it be easier if the "default stream" would just behave like a regular >> > package? >> > >> > I can think of two solutions of that: >> > >> > 1. (drastic for modular maintainers) >> > >> > We keep miantaining the default versions of things as ursine packages. We only >> > modularize alternate versions. >> > >> > Pros: Users who don't want alternate versions won't be affected by imperfections >> > of our modular design. No Ursa Major/Prime needed in the buildroot. >> > >> > Cons: Modular maintainers who do modules with just one stream because it is >> > easier for them would need to rollback to what's easier for everybody else but >> > them. Modular maintainers who do multiple modular streams would need to maintain >> > both the alternate streams and ursine packages. >> > >> > >> > 2. (potentially dangerous consequences?) >> > >> > We put the default modular stream into our regular repos, similarly to what we >> > try to do in the buildroot. "dnf install Foo" would install the Foo package and >> > would not enbale any streams or modules. The modular maintainers would keep >> > maintaining the modules as now, the infrastructure would compose the defaults >> > into the regular repo (or an additional but default-enabled one). >> > >> > Pros: Maintainers would keep doing what they desire. >> > >> > Cons: We would need to make this technically possible and figure out all the >> > corner cases (however AFAIK this needs to be done for the "modules in buildroot" >> > thing as well). >> > >> > WDYT? >> >> So despite providing zero feedback here, this was voted at the modularity meeting: >> >> * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37) >> * AGREED: We disagree with merging default streams into the main repo >> as non-modular packages. Our approach is to implement a mechanism of >> following default streams to give people the experience they want. >> (+4 0 -0) (asamalik, 16:07:40) >> >> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html >> >> I disagree strongly with the reasons provided in the logs, but clearly, we >> should aim for solution 1. if solution 2. is not negotiable by the modularity WG. > > > Why am I not getting rid of the feeling that Modularity is getting shoved down our throats no matter the objections we raise? > It's being pushed so hard because it has been promoted as a top level objective, and because it's in RHEL now, no one can afford to let it fail. It *has* to succeed for RHEL, and for Fedora to remain a natural upstream for RHEL, it *must* succeed here too. The problem is that the RHEL approach to modules only works because RHEL is centrally developed and can be correctly coordinated to overcome issues in the design. This is not true in Fedora, and there doesn't seem to be allowances for this difference. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
