Re: Modularity and the system-upgrade path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





This is a policy choice, not a technical matter. If modules became more
popular, and the dependencies between modules grew, we'd need
to settle on similar rules, where bigger changes are done with a certain
cadence. This is why I think that the "independent lifecycles for modules"
are illusory, made possible by current scarcity of modules.

Currently (F31), there are about 63 modules listed with dnf module list.
I have attempted to install all modules and all streams. Between single installations
I always reverted the system to its default state, i.e. modular repos enabled, but no
modules installed, enabled, disabled or anything.

From those 63 modules,
  • about 18 are not correctly defined according to criteria that I had agreed on with Stephen, https://pagure.io/modularity/issue/149.
  • about 8 modules cannot be installed because of some dependency problems: #1764546, #1764616, #1764623, #1764624, #1764606, #1764606, #1764611, #1764604
In some of the cases, packagers themselves report that the particular module should NOT be included
in that particular version of Fedora, currently 31, but they still ARE.

So, not just the tooling, the content is problematic as well, it is not ready and nobody seems to care, as there
are bugs reported that have not been resolved for several weeks. And since we do not currently block on modular sanity,
we cannot enforce anything.

As far as tooling is concerned, I have been seeing complaints about DNF doing a bad job, but from the perspective of acceptance
testing, it's the DNF operations that usually work fine with installing, enabling, disabling, removing, resetting and switching modules and streams.

I believe, that if modularity was opt-in, we would be able to use it just fine, as it is designed now with some little tweakings, such as DNF providing enough info on retired or discontinued streams, offering a possibility to choose a different stream to switch to on upgrades. The longing for default modular Fedora is what makes it more problematic, because we need to hide everything from the users and make everything work automatically. If modularity was a matter of personal choice we would not have to hide anything from anybody, because those users would be able to read the necessary documentation and tweak their systems just fine.

---

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka@xxxxxxxxxx   

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux