On 9 August 2017 at 03:39, Ralph Bean <rbean(a)redhat.com> wrote:
## Solution: "Input" Modulemd Syntax Changes
We’re going to extend the modulemd syntax to allow specifying multiple
dependencies in an "input" modulemd (the one that packagers modify). When
submitted to the build system, the module-build-service (MBS) will *expand*
these values under the hood, and submit **multiple** module builds to
itself based on the expansion.
Here are some examples of modulemd files (maintained by humans) that might be
submitted to the MBS.
Build on **all** active streams of the platform module.
On the Python SIG list, we've recently been discussing how we'd like
the Python module streams to be defined for F28+ (since we don't want
to make any major changes to the F27 plans at this late date), and we
think we've spotted a potential problem with the described approach
(depending on how "active stream" gets defined): it isn't clear how we
would handle introducing new streams that we wanted to be explicitly
opt-in only rather than opt-out.
As a concrete example, the upstream Python 3.7 alpha & beta cycle will
be running in parallel with the F28 development cycle. It would be
beneficial to be able to create the corresponding module stream once
the first alpha release is available, but we don't really want anyone
else to implicitly start building against that stream until it hits
the release candidate phase (as upstream's typical API and ABI
stability guarantees don't apply until after the last beta release).
Two potential solutions to that occurred to us:
1. Have a stream metadata attribute that controlled whether or not a
branch was considered active for implicit dependency declarations
(e.g. "active: no")
2. Replacing the idea of depending on active streams with the idea of
depending on "stream tags", such that the stream metadata would
include something like "tags: [active]", and you'd depend on all the
streams in a stream tag the same way you currently depend on a single
stream: "platform: active"
Of the two, the second one seems more flexible, and has the added
bonus of offering support for "stream aliases", since you'd be able to
do things like "tags: [f26, f27]" (for example) to indicate that a
stream was the default in particular versions of Fedora.
For ease of adoption of stream expansion, there could also be a notion
of making "active" an implied tag for any non-EOL stream, such that
you'd have to opt-out explicitly to mark a stream *in*active: "tags:
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia