On Wed, Oct 9, 2019, 12:29 Miro Hrončok <mhron...@redhat.com> 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? > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
