Provide C interface for modularity APIs

[jlebon]

Right now, AFAICT dnf module leverages the libdnf SWIG API for managing modules. This is an issue for C/Rust clients like rpm-ostree which also want to support modularity (coreos/rpm-ostree#1435).

Are those SWIG APIs considered stable/public at this point? Not having to support two interfaces would simplify things.

[cgwalters]

One thing tangentially related to this - I think we should be moving to running most of the libdnf stuff as a subprocess. This would allow us to drop privileges for it, and also help avoid things like the way librpm might call chroot() - so we'd end up with some sort of API (I was playing with ipc-channel in coreos/rpm-ostree#1680 ) wrapper around it.

Of course that inner subprocess would need to use C++ but the idea is we're avoiding intermixing C/Rust and C++ directly.

[Conan-Kudo]

There are some plans to rewrite dnfdaemon from ManaTools into C++ and integrate it into the libdnf project to provide a D-BUS based interface for clients. How this will happen and what that will look like exactly hasn't been hammered out yet.

But there are no plans to drop the direct library interface. The daemon will merely provide an extra mechanism.

[lukash]

One thing tangentially related to this - I think we should be moving to running most of the libdnf stuff as a subprocess. This would allow us to drop privileges for it, and also help avoid things like the way librpm might call chroot() - so we'd end up with some sort of API (I was playing with ipc-channel in coreos/rpm-ostree#1680 ) wrapper around it.

Of course that inner subprocess would need to use C++ but the idea is we're avoiding intermixing C/Rust and C++ directly.

Hi, this looks like something worth elaborating on. I'm not sure I understand you correctly but it seems to be an important design aspect.

On the point of intermixing C++ and C/Rust, I'm not sure how you mean it, you can't directly intermix the two. If we have C++ API in libdnf, you can't use that from either C or Rust (at least that was true for Rust some time ago and I don't expect that to change), the C++ API needs to be wrapped in C API (either as part of libdnf, which is what our plan is, or alternatively as an external wrapper). So that's the way to do it and I think our plan how to cater to coreos.

What are the specific reasons for you to have libdnf code running as a subprocess? Those reasons are important, because using a subprocess is quite a change in design. As @Conan-Kudo said, we are planning on providing a D-BUS daemon (which solves issues like having to be root), and that is quite probably what you'd want to use if you wanted to have libdnf in a different process (instead of forking it directly)?

I suppose you cold also use the C++ and wrap that in some sort of IPC to for k as your own subprocess, but I'm not sure there are good reasons to do that.

The thing is, I think coreos is one of the major consumers of the planned C API (it may be the only one?), so if you ended up preferring to use the D-BUS API and the daemon, I assume the priorities for the C API would suddenly go down quite a bit (and the daemon would raise in priority).

My $0.02, hope it's making sense to you.

[cgwalters]

Sorry, my mentioning of subprocessing was unnecessary and added too much confusion here.

Today, rpm-ostree's code is deeply entangled with the libdnf APIs; having C instead of C++ APIs would definitely be helpful in the short term.

[LorbusChris]

This issue has been dormant for 10 months now - I wonder what we can do to get some traction on the issue?

[Conan-Kudo]

There is a gobject-based C interface for modularity with the release of libdnf 0.55.2. It is used in microdnf 3.5.1.

[jlebon]

Looking more closely at this (while trying to implement support for it in rpm-ostree), it seems like this is missing the most crucial bit, which is exposing ModulePackageContainer::install(). Otherwise, there isn't any way to actually install modules. Can we re-open this?

[Conan-Kudo]

I suppose so. Micro DNF just implements enable/disable/reset and lets the normal install command work, but I guess you want to implement the all-in-one workflow too?

[jlebon]

The API I'm trying to go for is something like this in the treefile:

modules:
  - cri-o:1.20

This should enable the module, and mark it for installation. I could use dnf_context_install() for the latter, but I want something more explicit there because dnf_context_install() is not modularity aware so e.g. nothing actually stops it from picking a bare package.

[Conan-Kudo]

That's not correct. If you've enabled modules, they get factored into the solution process afterward. Otherwise microdnf would not be able to install the correct stuff from modules after users enabled/disabled/reset module states.

[jlebon]

Hmm OK cool, that does work correctly. But we still need an API to be able to install modules at the profile level rather than the package level.

Edit: started hacking on a patch to add dnf_context_module_install.

[jlebon]

I guess for rpm-ostree just like dnf we'll need to allow both cases, i.e. installing a module by profile and installing specific packages within a module. Need to think a bit on the cleanest declarative UX to represent these.

[jlebon]

#1200