On Wed, Aug 5, 2020 at 6:17 PM James Cassell <fedoraproj...@cyberpear.com> wrote: > > As general feedback, the footnotes make it hard to read the rendered version > of the document, forcing me to scroll up and down. >
Well, the idea is that the footnotes are additional information providing justification for the policy. You should only need to look there if you care *why* you're required to do something. I didn't want that extra info cluttering the policy itself, so I footnoted them. > 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? > That's not really a policy question, but it's *possible* that we could do that as part of the compose. I don't see a lot of reason to do so, since a local MBS build will handle it for you and as we establish later on, the use of these should be a last resort, not a common practice. > Do these "non-shipped" packages shadow non-modular versions of the same > packages? > They would shadow non-modular versions if we allowed them into the repository, hence why they are not composed there. > > == 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. We looked into that a while ago. The short answer is "it's a lot harder to accomplish than it sounds" (particularly if you have buildonly content required, such as relying on a too-new-for-Fedora version of a build-system or something). If you want to propose a possible way of doing this, please start a different email thread, as it is off-topic for the policy discussion. > > 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. > Please do not derail this thread with a re-architecture of Modularity. The shadowing is a core part of the functionality. What would even be the point of being a default stream if your packages weren't visible to the depsolver? (Don't answer that in this thread, please.) > > * 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. EPEL 7 doesn't support modules and EPEL 9 hasn't been announced yet and has no policy established. EPEL 8 is the only one that has made a decision either way. > > > * 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" Good catch. I will fix that. _______________________________________________ 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
