As general feedback, the footnotes make it hard to read the rendered version of the document, forcing me to scroll up and down. More comments below. On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote: > * If a stream of a module has build-time-only components, all such > components *MUST* be marked as `buildonly: True` in the module > metadata to avoid shipping them to users and polluting their > repository. > Can these be directed to a disabled-by-default build-dep repo of some kind for those trying to do local builds? Do these "non-shipped" packages shadow non-modular versions of the same packages? > == Requirements for Default Streams I'd propose an alternative to Default Streams. Any package part of a default stream should instead be auto-built in a given release where the stream is marked as default. Pushes to the dist-git branch for that release would be blocked by all but the auto build bot, and all changes should be made to the stream branch. The stream marked "default" for the particular module would be enabled as a buildroot override, including build only packages, for such automated non-modular rebuilds of streams marked "default". This would obviate the need of stream transition, except in cases if inter-module deps. Even given the status quo, I'd argue that streams enabled by nature of being Default rather than being explicitly enabled, should not shadow non-modular packages. As-is today, third party repos are marking themselves as module_hotfixes to skip the shadowing issues. > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN > permits defaults streams that adhere to the policy below. Say EPEL, don't mention version. > * Default streams *MUST NOT* provide a binary RPM with the same > package name as an RPM in a default stream in the same release except "default stream of another module" > in the case of a transition from one to the other.footnote:[In this > situation, whichever has the highest NEVRA would win the depsolving > and could break the other module.] V/r, James Cassell _______________________________________________ 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
