I'm not sure it needs to be mentioned in the change proposal - but there are some caveats to this as it applies to the workstation:
* There are no plans to add any user interface to enable/disable modules in the GNOME Software user interface. * If we even want graphical applications from enabled modules to appear in GNOME Software, someone is going to have to put work into appstream enabling modules, and into filtering the appstream data based on enabled modules. * For Fedora Silverblue, if we want users to be able to layer rpms from modules, then rpm-ostree will likely need work. For the Workstation in general we want to move to a model where the system install set is stable and enables basic functionality, and containers are where you do sysadmin experimentation and development. Silverblue is the long-term version of this, but we encourage this way of working even for RPM-based installations. So ideally documentation about trying out modularity on Fedora Workstation for something like a different version of nodejs would show doing that inside a container. (With the caveat that we're still figuring out what the recommended best practices are for pet containers.) Owen On Wed, Jun 20, 2018 at 1:14 PM, Jan Kurik <jku...@redhat.com> wrote: > = Proposed System Wide Change: Modules for Everyone = > https://fedoraproject.org/wiki/Changes/ModulesForEveryone > > > Owner(s): > * Stephen Gallagher <sgallagh at fedoraproject dot org> > * Langdon White <langdon at fedoraproject dot org> > > > All Fedora installations will have modular repositories enabled by > default, previously available, by default, only to Server Edition. > > > == Detailed description == > In Fedora 28, the Server Edition debuted new modular functionality, > allowing end-users access to alternative versions of popular software. Due > to technical limitations with package-management software, it was not > available for non-Server deployments of Fedora. Beginning with Fedora 29, > all installations of Fedora will have modules available for installation > and update. This will be done by merging the `fedora-repos-modular` > sub-package back into the `fedora-repos` package. > > > == Scope == > * Proposal owners: > The proposal owners need to coordinate the work of the DNF team and > release-engineering to make sure that the repo subpackage merge only > happens once the libdnf enhancements are stable. We will also need to > prepare and run a Fedora Test Day with the QA team. > > * Other developers: > The DNF team is already committed to providing the necessary changes for > libdnf in Fedora 29. > > * Release engineering: > #7561 [https://pagure.io/releng/issue/7561] > > ** List of deliverables: > All Fedora installations > > * Policies and guidelines: > No alterations to packaging guidelines are required specifically for this > change > > * Trademark approval: > N/A (not needed for this Change) > -- > Jan Kuřík > JBoss EAP Program Manager > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. > fedoraproject.org/message/NBD45XW5275VWVTLEYH5IHAJBK5T35ZF/ > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OJ5Q3B7OAU5TAUBJPG3FGALEYZCJNVMM/
