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@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
--
Alexander Kurtakov
Red Hat Eclipse Team_______________________________________________ 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
