On Thu, Oct 10, 2019 at 12:52 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 09. 10. 19 22:46, 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. > > If this is the goal of default modular streams, wouldn't it be in fact much > easier to keep the default versions as urisne packages? That means, you have 2 different workflows: for default version and for an additional one. When branching happens, instead of just updating one file which points to the new default, you would have to create new stream, retire the one which is about to become default and update package in non-modular. > > 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`. > > What I miss in the description is: > > 1. How does this thing actually work? is there an additional repository composed > from the default streams available in Koji only? > > 2. How are conflicts between packages from the default streams and ursine > package be handled? > > 3. What is the local experience if the packager is using mock. What if they are > using rpmbuild directly? > > 4. How are we handling default streams with dependencies on non-default streams > of other modules? > > > ... > > == 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. > > What are the packagers of ursine packages that are shadowed by their modular > counterparts supposed to do here (assuming such shadowing happens)? > > What are the packagers of modular packages that are shadowed by their ursine > counterparts supposed to do here (assuming such shadowing happens)? > > > ... > > == 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. > > How can I test this as an ursine package maintainer assuming I have build > dependencies that were ursine packages but now will be form modules? > > > ... > > == Contingency Plan == > > * Contingency mechanism: Disable the buildroot inheritance in Koji to > > revert to the current behavior. > > Assuming ursine packges will be retired from Fedora, what is the contingency > there? Consider this scenario: > > 1. maintainers of the ook module welcome this change and finally they retire ook > from ursine Fedora, shipping only the default ook:12 modular stream. > 2. maintainers of ook-cool and ook-free happily build against modular ook:12 > 3. a previously unknown fundamental flaw in design triggers the contingency plan > 4. ook-cool and ook-free FTBFS, maintainer of ook do no longer wish to maintain > ook as ursine package, because the entire depndncy tree to make that happen was > gone/updated/downgraded in the meantime > > Who will revert ook to the previous working state? Is it the change owner? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > 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 _______________________________________________ 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
