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

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

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.

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to