On 04/10/2019 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?
+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.
That sounds very reasonable to me! We would have a clean "core" again
without the complexity of Modularity enabled by default. Having it as an
optional solution for additional streams still gives the maintainers the
power to support different versions and the power users the choice.
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).
Also sounds reasonable to me, although I prefer 1. this should also
solve the current issues.
WDYT?
First of all: Thank you very much for your proposal, I think it is a
very important point! I think we should stop developing Modularity in
that too complex way we have now and go to a less complex and more
optional (for both maintainers and users) implementation. As I wrote
above, I prefer option 1 as it should be the easier, less complex
design. But also your second option should improve things.
Greetings,
Christian
_______________________________________________
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
