On Tue, 2017-08-08 at 13:39 -0400, Ralph Bean 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. That sounds like a very powerful idea! I see two different possible motivations for this, one good, and one maybe not so much. The good: if you have a component like 'httpd' that's part of your application, it's pretty clear that you don't want your choice of httpd version to force you into a particular Fedora platform and a particular version of all your other components. The bad: you have a Fedora system installed with the f27 version of the Host module. You want to install an application on top of that, so you need to have the application available built on the f27 runtime. One reason I don't like the second motivation is that it feeds the thinking that modules can be arbitrarily combined within the same namespace, and they cannot. Even if two modules are built against the same runtime, the same version of Python, they still can have conflicting versions of libraries. That's basically the point of modularity. But beyond that, if maintainers think that their application module has to be built and tested against every active platform version (plus whatever other combinatorial explosion users ask for), then any simplification that modularity provides to packagers is gone, and instead people will be constantly fighting library compatibility and adding conditionals, and generally tearing their hair out. So I think we need to be very clear in the expectations that we're setting for module maintainers - that this is a new tool in the toolbox of a maintainer, not a hoop that they have to jump through. And if it makes sense to package your module as a container or a flatpak then that is an entirely satisfactory way to handle combining your module with modules built on a different platform version. Owen _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
