On 9 August 2017 at 03:39, Ralph Bean <rbean@xxxxxxxxxx> 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. > dependencies: > buildrequires: > platform: [] 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: [-active]" Thoughts? Cheers, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
