Building modules in Copr

Copr ("Community projects") is a service that builds your open-source projects and creates your own RPM repositories. Read the documentation to find out more or see it in action here.

There are multiple ways how to build modules in Copr and it is up to each user to choose the most suitable one for their specific use-case.

Discover more advanced topics such as requiring Copr packages from an existing modulemd yaml file, depending on modules from Copr, and overriding module packages by regular ones.

Copr is a third-party service with its own implementation of the module build process. It does not rely on the Module Build Service and it is not governed by Fedora Modularity team. As a consequence, some features might behave differently.

Some features are also in rather experimental or proof-of-concept state (e.g. depending on other Copr modules) and therefore might be cumbersome to use. Feedback from users is more than welcome and it is the deciding factor of what is going to be implemented or improved. Please submit your requests to pagure issue tracker.

Additionally, only version 1 of the modulemd format is supported. Version 2 is not supported yet (with an exception of version 2 files that are compatible with the older format).

Currently, there is no web UI for submitting a module build from an existing modulemd yaml file. The only way is to use copr-cli package. Make sure it is installed.

And make sure that an API token is properly configured.

To submit a build from locally stored modulemd yaml file, use:

If the modulemd yaml file is available on a URL accessible for public, use following:

To specify a different project owner (e.g. when building into a group project), use:

For more information, see copr-cli build-module --help or man copr-cli.

This method aims to provide modularity features with the lowest entry barrier possible. It doesn’t demand a user to know either how to write modulemd yaml file nor using the command line. The only prerequisite is to have a Copr project with some package successfully built in it.

Open your project, click on Modules, then click to New Module. The input page looks like this.

It provides a list of all successfully built packages in the project. By default, they are all selected to become part of the module. Uncheck those that are not wanted. Optionally specify a module API or its profiles.

It is trivial to achieve when generating modulemd from Copr project. This section describes a special case of how to add a Copr package into an existing custom modulemd yaml file.

Update components.rpms section and add a new package definition.

The …​ placeholders need to be replaced with real values. Open a web browser and navigate to a build detail whose results should be used by the module. The build needs to be finished successfully. Scroll down to the Results section.

To avoid confusion, here are some example values.

At this moment, Copr doesn’t properly parse module dependencies from modulemd yaml file. They need to be explicitly enabled in the project settings - more precisely chroot settings within a project.

When the dependency comes from Fedora repositories, simply edit Enable module field and append the module in name:stream format.

If the dependency was built in Copr, it is necessary to edit also the Repos field and provide a repository URL from which the module can be installed. See the Installing modules from Copr section to learn how to find a repofile for a module (in this case the module that is used as a dependency). Use it’s baseurl as the value for Repos field.

Currently dnf copr plugin does not support enabling module repositories and therefore it needs to be done manually. Navigate to a Copr project in a web browser, see the Modules page, and open detail of a module that is to be installed. If the build is still running, wait until it finishes. For successfully built modules, a "How to use" section is displayed. Follow its instructions. After that, standard DNF commands for manipulation with modules can be used.

See https://docs.fedoraproject.org/en-US/modularity/installing-modules/

The package version resolution was straightforward in the pre-modularity era. If multiple repositories provided the same package, the one with the highest version was preferred. It is more complicated now. If there is a module stream enabled within the system and this stream provides a package, it is preferred over its non-modular variant regardless of its version.

To suppress this behavior, module_hotfixes repositories were invented. For them, DNF upgrades to a higher version of a package regardless of where it comes from. Enable them in Copr by going to project settings and turning on this checkbox.

Or in a command line

Build a module from a modulemd yaml file hosted online:

Alternatively, build a module from a localy stored modulemd yaml file: