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....
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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