Miro Hrončok wrote:
> Wouldn't it be easier if the "default stream" would just behave like a
> regular package?
+1
> 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.
In other words, this proposal would ban module-only packages, allowing
modules only for alternate versions? IMHO, that is the most reasonable
approach, but:
> 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).
If that works out, that sounds acceptable to me as well. As long as I am not
forced to use or care about modules, this works for me.
> WDYT?
I think either of your 2 proposals needs to be implemented ASAP. They are
both much saner than the overengineered and error-prone solutions the
Modularity team is proposing for this blocker (see Stephen Gallagher's mail
that started this thread). Seeing how DNF already has trouble meeting user
expectations in corner cases (e.g., with Obsoletes, with weak dependencies,
etc., and now also with Modularity), I don't think expecting more complex
behavior from it is going to work out well.
Kevin Kofler
_______________________________________________
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
