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
>> 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
> I can think of two solutions of that:
> 1. (drastic for modular maintainers)
> We keep miantaining the default versions of things as ursine packages.
> modularize alternate versions.
> Pros: Users who don't want alternate versions won't be affected by
> of our modular design. No Ursa Major/Prime needed in the buildroot.
> Cons: Modular maintainers who do modules with just one stream because it
> easier for them would need to rollback to what's easier for everybody
> them. Modular maintainers who do multiple modular streams would need to
> both the alternate streams and ursine packages.
> 2. (potentially dangerous consequences?)
> We put the default modular stream into our regular repos, similarly to
> try to do in the buildroot. "dnf install Foo" would install the Foo
> would not enbale any streams or modules. The modular maintainers would
> maintaining the modules as now, the infrastructure would compose the
> 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
> corner cases (however AFAIK this needs to be done for the "modules in
> thing as well).
So despite providing zero feedback here, this was voted at the modularity
* 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)
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
Why am I not getting rid of the feeling that Modularity is getting shoved
down our throats no matter the objections we raise?
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines