Early module development with Fedora Modularity
So you like the Fedora Modularity project – where we separate the lifecycle of software from the distribution – and you want to start with module development early? Maybe to have it ready for the modular Fedora 26 Server preview? Start developing your modulemd on your local system now, and have it ready for later when the Module Build Service is in production!
Defining your module
To have your module build, you need to start with writing a modulemd file which is a definition of your module including the components, API, and all the information necessary to build your module like specifying the build root and a build order for the packages. Let’s have a look at an example Vim module:
document: modulemd version: 1 data: summary: A ubiquitous text editor description: > Vim is a highly configurable text editor built to make creating and changing any kind of text very efficient. license: module: - MIT content:  xmd: ~ dependencies: buildrequires: generational-core: master requires: generational-core: master references: community: http://www.vim.org/ documentation: http://www.vim.org/docs.php tracker: https://github.com/vim/vim/issues profiles: default: rpms: - vim-enhanced minimal: rpms: - vim-minimal graphical: rpms: - vim-X11 api: rpms: - vim-minimal - vim-enhanced - vim-X11 filter: rpms: ~ components: rpms: vim-minimal: rationale: The minimal variant of VIM, /usr/bin/vi. vim-enhanced: rationale: The enhanced variant of VIM. vim-X11: rationale: The GUI variant of VIM. vim-common: rationale: Common files needed by all VIM variants. vim-filesystem: rationale: The directory structure used by VIM packages.
Notice that there is no information about the name or version of the module. That’s because the build system takes this information from the git repository, from which the module is build:
- Git repository name == module name
- Git repository branch == module stream
- Commit timestamp == module version
You can also see my own FTP module for reference.
To build your own module, you need to create a Git repository with the modulemd file. The name of your repo and the file must match the name of your module:
$ mkdir my-module $ touch my-module/my-module.yml
The core idea about modules is that they include all the dependencies in themselves. Well, except the base packages found in the Base Runtime API – which haven’t been defined yet. But don’t worry, you can use this list of binary packages in the meantime.
So the components list in your modulemd need to include all the dependencies except the ones mentioned above. You can get a list of recursive dependencies for any package by using repoquery:
$ repoquery --requires --recursive --resolve PACKAGE_NAME
When you have this ready, you can start with building your module.
Building your module
To build a modulemd, you need to have the Module Build Service installed on your system. There are two ways of achieving that:
- Installing the module-build-service package with all its dependencies.
- Using a pre-built docker image and a helper script.
Both options provide the same result, so choose whichever you like better.
Option 1: module-build-service package
On Fedora rawhide, just install it by:
$ sudo dnf install module-build-service
I have also created a Module Build Service copr repo for Fedora 24 and Fedora 25:
$ sudo dnf copr enable asamalik/mbs $ sudo dnf install module-build-service
To build your modulemd, run a command similar to the following:
$ mbs-manager build_module_locally file:////path/to/my-module?#master
An output will be a yum/dnf repository in the /tmp directory.
Option 2: docker image and a helper script
With this option you don’t need to install all the dependencies on your system, but it requires you to setenforce 0 before the build. 🙁
You only need to clone the asamalik/build-module repository on GitHub and use the helper script as follows:
$ build_module ./my-module ./results
An output will be a yum/dnf repository in the patch you have specified.
The next step would be installing your module on the Base Runtime and testing if it works. But as we are doing this pretty early, there is no Base Runtime at the moment I’m writing this. However, you can try your module in a container using a pre-build fake Base Runtime image.
To handcraft your modular container, please follow the Developing and Building Modules guide on our wiki which provides you all the necessary steps while showing you a way how modular containers might be built in the future infrastructure!
Are you visiting DevConf.cz in Brno? There is a talk about Modularity and a workshop where you can try building your own module as well. Both can be found in the DevConf.cz 2017 Schedule.
- Day 1 (Friday) at 12:30 – Fedora Modularity – How does it work?
- Day 2 (Saturday) at 16:00 – Fedora Modularity – Build your own module!
See you there!