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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
_______________________________________________ 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
