On Wed, Oct 9, 2019 at 4:47 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot > > Enable module default streams in the buildroot repository for modular > and non-modular RPMs. > > == Summary == > This Change (colloquially referred to as "Ursa Prime") enables the > Koji build-system to include the RPM artifacts provided by module > default streams in the buildroot when building non-modular (or > "traditional") RPMs. > > == Owner == > * Name: [[User:Sgallagh| Stephen Gallagher]] > * Email: sgallagh@xxxxxxxxxx > * Responsible WG: Modularity WG > > == Detailed Description == > As a major part of the Modularity design, we have a concept of default > module streams. These streams are built as modules, but the RPM > artifacts they deliver are intended to be used just like non-modular > RPMS. The aspirational goal is that a user of the system who never > executes a module-specific command (such as `dnf module install > nodejs:8`) should experience no meaningful changes in behavior from > how they would interact with a completely non-modular system. In > practice, this may mean that the informational output of package > managers may indicate that modules are being enabled and used, but a > user that does not have a specific reason to interact with the > selection of a module stream should have that managed on their behalf. > > Similarly, the experience for package maintainers of non-modular > packages should be unaffected by an RPM dependency moving from the > non-modular repository into a default module stream. Up to the > present, this has not been the case; no module stream content has been > available in the non-modular buildroot for other packages to consume. > Koji builds of non-modular RPMs have had only the other non-modular > RPMs from that release available to their buildroots. In contrast, > building on local systems has access to both the non-modular RPMs and > the RPMs from any of the default module streams. With this Change, > Koji builds will have the same behavior and be able to depend on > content provided by default module streams. It also enables the same > behavior for Modular builds: the `platform` stream will now include > the contents of the default module streams for each release and do not > need to be explicitly specified in the modulemd `buildrequires`. > > Note: This Change does not address the other major Modularity issue we > are facing around distribution upgrades with differing default > streams. When discussing this Change, please keep that topic separate. > > == Benefit to Fedora == > > This will simplify the lives of package maintainers in Fedora in two > primary ways. I'll use a hypothetical example of the Node.js > interpreter and a JSApp package which is capable of running on Node.js > 10 or 12 (but requires newer features than are provided by Node.js 8). > Additionally, the JSApp package requires the same versions of Node.js > at build-time. > > * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module > streams. The `nodejs:10` stream is set as the default stream. > * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module > streams. The `nodejs:10` stream is set as the default stream. > * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The > `nodejs:12` stream is set as the default stream. The `nodejs:14` > stream will likely become available during the F31 lifetime. > * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The > `nodejs:12` stream is set as the default stream. The `nodejs:14` > stream will likely become available during the F32 lifetime. > > On Fedora 29 through 31, the Node.js package maintainer needs to build > the `nodejs:10` package both as a module and as a non-modular RPM in > the distribution so that the JSApp package can be built. With this > Change, the Node.js package maintainer in Fedora 32+ will only need to > build the various Node.js streams and make one of them the default > stream. The packages from it will then be added to the buildroot for > non-modular packages. This will also make the packaging process > somewhat more efficient, as the maintainer needs only to manage the > module stream and the MBS will build it for all configured platforms. > > Similarly, from the perspective of dependent maintainers, there will > no longer be anxiety about needing to move their package to a module > if one or more of their dependencies drops their non-modular version > in favor of a default stream. Their builds will continue to work as > they do today. > This might be a dumb question (perhaps I missed the answer somewhere in the thread), but how do we handle setting overrides for modular content? Without that, it's going to be hard to do modular update to fix non-modular builds... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
