# Modularity for openSUSE Leap Next

## Problem description

Leap is the number one choice in the (open)SUSE ecosystem for users and developers that wish to have a stable community distribution. However, as Leap grows older its core libraries become increasingly outdated, as these are inherited from SLE which has high stability guarantees.

While this is understandable and makes sense, it hinders Leap's adoption as a developer and user platform: as the system grows older it becomes harder and harder to build applications with the outdated set of libraries. Also, developers can no longer simply install the latest version of their dependency without either resorting to external package managers or adding development projects on OBS.

## Modularity

Fedora's modularity initiative provides a possible solution for this too-fast-too-slow problem: packages can provide multiple streams with custom EOL dates that are independent of the distribution's EOL. Furthermore, modular repositories support build time only dependencies, that are not visible to the repository's consumers.

This can solve some of the "annoyances" of a stable distribution:
- package maintainers can easily include build time dependencies without having to worry that these will override anything in the user's system
- developers can consume the latest libraries from the system's package manager without having to search for the correct development project on OBS
- package maintainers will be more willing to ship their software for Leap, as they can set far shorter EOL dates

## What needs to be done

- [x] ship the modularity related tools in Leap (should be already present)
- [ ] add support for modular repositories in `zypper` **or** switch to `dnf`
Note that [OPENSUSE-3](https://jira.suse.com/projects/OPENSUSE/issues/OPENSUSE-3) proposes to switch to `dnf` for Leap as well, thereby solving this issue as well.
- [ ] add support for creating modular repositories in OBS (OBS can at the moment only parse modular repositories, but not create these)
This should include a convenient way how a module can be created from a project. Ideally there should be also a way how multiple versions of the same package can be managed to fully leverage the power of modularity.

* how to handle migration/updates? (→ look at `dnf module reset`)

## Alternative solutions

An alternative solution is to provide compatibility packages, e.g. next to `libfoo`, also `libfoo-1.2`. This has one major advantage over modular repositories: `libfoo` and `libfoo-1.2` can be co-installed, while two streams of the same module can not.

However, this does not solve the issue that this library must be maintained for the rest remaining lifetime of the distribution (especially if it is just required for building), which is a major detergent for a package maintainer. Additionally it requires a lot of duplication that could be avoided if package maintainers could simply produce modular repositories from projects on OBS into which they link their respective dependencies and filter out anything that users don't need (test dependencies, any build requires, `-devel` subpackages, etc.).

Producing modular repositories on OBS could be made very simple due to its ability to link packages from other projects. Package maintainers could simply link all their required dependencies from e.g. Factory, add their source package and setup filter rules to only expose the actual `Requires:`. This would be far more convenient and would scale much better in contrast to manually copying a snapshot of `libfoo` from Factory to Leap as `libfoo-1.3`, as this will require renames and no updates from Factory will be automatically applied to `libfoo-1.3` (which they would if it was a `_link`).