On Wed, Aug 5, 2020 at 6:17 PM James Cassell
<fedoraproject(a)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.