On Sunday, October 13, 2019 11:42:41 PM MST Aleksandar Kurtakov wrote: > On Mon, Oct 14, 2019 at 9:00 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > > wrote: > > On Wednesday, October 9, 2019 1:46:52 PM MST Ben Cotton 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. > > > > > > == Scope == > > > * Proposal owners: > > > # Update Packaging Guidelines with > > > [https://pagure.io/modularity/issue/146#comment-600328 requirements] > > > for module default streams > > > # Create a Pungi configuration to generate the buildroot from the > > > default module streams. > > > # Include `default_modules_scm_url` in the platform virtual module > > > specification > > > > # Configure Koji tags for inheriting the new > > > > > modular-defaults > > > buildroot into the standard buildroot > > > > > > * Other developers: > > > > > > Packagers of default module streams will be required to conform to the > > > [https://pagure.io/modularity/issue/146#comment-600328 policy] > > > regarding visibility of stream artifacts. Any default module stream > > > that is not in compliance by one week before Beta Freeze will cease to > > > be a default stream. > > > > > > * Release engineering: > > > # https://pagure.io/releng/issue/8879 - Create pungi config for > > > Rawhide/F32 ursa prime buildroot > > > # https://pagure.io/releng/issue/8880 - Include > > > `default_modules_scm_url` in platform 31 virtual module > > > # https://pagure.io/releng/issue/8881 - Configure Koji tags for > > > inheriting f32-modular-buildroot > > > > > > * Policies and guidelines: > > > The Modularity Packaging Guidelines will need to be updated to > > > indicate the strict requirements on default streams. > > > * Trademark approval: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > > This change is on the build-system side of things and should not > > > impact the upgrade process directly. > > > > > > == How To Test == > > > # Build a modular stream > > > # Make that stream a default stream (or a buildroot override) > > > # Build a non-modular RPM that requires an artifact RPM from the modular > > > stream. > > > > > > == User Experience == > > > This should not change the end-user experience. > > > > > > == Dependencies == > > > Nothing known that isn't listed in the scope. > > > > > > == Contingency Plan == > > > * Contingency mechanism: Disable the buildroot inheritance in Koji to > > > revert to the current behavior. > > > * Blocks release? Ambiguous: lack of complete implementation may > > > indirectly cause blocking issues. > > > * Blocks product? No > > > > > > == Documentation == > > > > > > > > > == Release Notes == > > > None needed, the Change is not user-facing. > > > > > > -- > > > Ben Cotton > > > He / Him / His > > > Fedora Program Manager > > > Red Hat > > > TZ=America/Indiana/Indianapolis > > > _______________________________________________ > > > 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@xxxxxxxxxxxxxxxxxxxxxx > > g > > > > That sounds like a really bad idea. Isn't the entire goal for traditional > > RPMs > > to exist separately from modules? This will lead to more packages being > > maintained as modules only, and I can only see it getting worse from > > there. > > > > Are there any actual benefits to this? I can't think of any. > > IMHO it's exactly the opposite. E.g. Eclipse is moving to a module because > it requires Maven 3.6 which is available as a module only. If this was > implemented earlier we wouldn't have bothered making Eclipse module. To > continue if this is delayed osgi/swt apps which depend on parts of eclipse > will find it easier to just make their apps modules too and so on. > > > -- > > John M. Harris, Jr. > > Splentity > > > > _______________________________________________ > > 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@xxxxxxxxxxxxxxxxxxxxxx > > g It seems that you just proved my point.. You decided to make Eclipse a module because somebody decided to make Maven 3.6 a module, instead of just shipping the latest stable version of Maven as a traditional package. -- John M. Harris, Jr. Splentity _______________________________________________ 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
