On Mon, Oct 14, 2019 at 10:43 AM Aleksandar Kurtakov <akurt...@redhat.com> wrote: > > > > On Mon, Oct 14, 2019 at 10:13 AM John M. Harris Jr <joh...@splentity.com> > wrote: >> >> 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 <joh...@splentity.com> >> > >> > 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: sgall...@redhat.com >> > > > * 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@lists.fedoraproject.org >> > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > > > 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/de...@lists.fedoraproject.or >> > > 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@lists.fedoraproject.org >> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > > 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/de...@lists.fedoraproject.or >> > > 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.
(snip) > You seem to totally miss the point - there is no one even trying to ship > Maven as a traditional package so what should we do give up on having > anything built with Maven in the distro? Or someone will jump and do the > needed work? I keep hearing these arguments but I'm yet to see someone > actually stepping in to the work. > This is clear example of "the one who does decides". You seem to have missed that, in fact, people *did* show up and started doing the work to keep the non-modular Java stack in a working state. That was *the whole point* of starting the Stewardship SIG. And arguably, the non-modular stack might soon be (or already is?) in better shape than the modular branches. Only a few major updates are still missing, among them the update to maven 3.6, which we've just not started working on yet, since it's a big update that affects almost all other Java packages. Fabio >> >> >> -- >> John M. Harris, Jr. >> Splentity >> >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> 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@lists.fedoraproject.org > > > > -- > Alexander Kurtakov > Red Hat Eclipse Team > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
