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@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: sgallagh@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-leave@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.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-leave@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.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.

--
John M. Harris, Jr.
Splentity

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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