On Wed, Aug 5, 2020 at 6:17 PM James Cassell <fedoraproject@xxxxxxxxxxxxx> 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@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
