To build a modulemd, you need to have the Module Build Service installed on your system.
Install it like this:
$ sudo dnf install mock-scm module-build-service
mock-scm currently needs to be installed explicitly
due to a missing runtime dependency declaration in the
module-build-service RPM.
Then add your user to the mock group:
$ sudo usermod -a -G mock myusername
To build your module, run a command similar to the following in the local git repository of your module:
$ mbs-build local
With the default configuration, this should generate a yum/dnf repository
beneath the directory modulebuild in the home of the user.
To test your local build environment on Fedora, the haproxy module is a
reasonable example module to start with:
$ fedpkg clone --branch f26 modules/haproxy
$ cd haproxy
$ sudo mbs-build local
Note
As an interim bootstrapping technique, many of the F26 Boltron modules will
download and cache around 15k RPMs from Koji as potential build dependencies.
haproxy is recommended as an example module specifically because it
doesn’t do that and instead only downloads what it needs to build the RPMs
it contains.
Replacing that bulk download with proper build dependency management more generally is part of the work being undertaken in F27.
Normally, the module build service obtains all build-time dependencies of your
module from the Koji server. If you want to build multiple modules depending on
each other you can do that by using the --add-local-build (or -l)
option of mbs-build.
Note
This option is only available in version 1.3.26 or later of the module build service.
For example, to build a module against a locally built perl module, you
can do the following:
$ mbs-build local --add-local-build perl
Specify multiple local module builds like this:
$ msb-build local --add-local-build perl --add-local-build python
You can even specify particular streams and versions of local module builds which should be used as dependencies:
$ mbs-build local -l perl:master -l python:master:2017080910103423