dnf5
dnf5 copied to clipboard
rpm-software-management
WITH_MODULEMD CMake Option Is Not Excluding Compilation With modulemd-2.0
When trying to build dnf5 from the dnf5.spec in this repository, I am running into an issue where I cannot compile without modulemd. I am building with most all of the extras outside of the core package turned off (modulemd, zchunk, perl, ruby, etc) to get the "leanest" version possible. I am currently working on version 5.0.14, though it doesn't appear to have any difference in the includes vs the current version.
Is modulemd-2.0 meant to be an optional package or a build requirement for libdnf5? hardcoded #includes are in the libdnf5/module directory forcing a dependency on this.
I found that there is a WITH_MODULEMD cmake option that doesn't seem to serve any functional purpose, at least when compared to WITH_COMPS or WITH_ZCHUNK which exclude the CMake requirement of these packages specifically.
Hi, you're right. It appears that there was originally an intention to make the modulemd dependency optional, but currently, it remains in an unfinished state.
@j-mracek, please do you have an estimate of the effort required to complete this? Briefly looking into the code, it seems that the modules are scattered in many places, indicating a non-trivial amount of work.
I agree that the work is not trivial but not too difficult, but it will require maintenance because modularity is still under development.
The compilation without modulemd-2.0 is important for distributions that never used modules therefore they have no libmodulemd in distribution.
The feature might be interesting for containers where we don't have to support modules. The support of modules will be not required in Fedora 41 (Fedora 40 requires a support of modules due to upgrade path from Fedora 38).
@mcurlej May I ask you for your opinion?
In DNF5 we implement Modularity for legacy reasons mostly. The feature set is limited to basic commands and nothing else. Currently not all of the basic commands are yet implemented. To be able to build DNF5 without modulemd is a valid request. But it is not a high priority.
@j-mracek While the changes are non-trivial, do you know what they entail? I am considering making a temporary set of changes until the feature is implemented. Is this mostly limiting the scope of building the libdnf5/module folder in CMake and adding directives to the locations that reference any of the produced objects? Or am I missing a critical component here?
The code that should be handled is not only in libdnf5/module. There are DNF5 commands, modular filtering applied during loading repositories. Creation of transaction tables, system state where it stores information about modules. But core part is in libdnf5/module and DNF5 commands.
When the build option is functional, I think it would be good to enable a build and test with build flag to ensure that additional changes in modularity would not brake it. I think this is the most difficult part - keep it functional.
As already mentioned in https://github.com/rpm-software-management/libdnf/issues/641 a couple of years ago, I am also interested in being able to build dnf(5) without libmodulemd.
