rpm-software-management / dnf5

Next-generation RPM package management system
Other
259 stars 87 forks source link

systemd-sysext integration proposal #1731

Open cgwalters opened 2 months ago

cgwalters commented 2 months ago

There's a lot of update of systemd-sysext and I see potential integration points dnf could do here.

For image based (e.g. bootc) systems...if dnf is part of the base system (as we support right now) one thing we could do is basically dnf install --sysext foo bar baz and dnf upgrade --sysext.

Here's how that'd work and what it'd do:

(We'd also support dnf --sysext remove foo but only for things in that sysext)

cgwalters commented 2 months ago

BTW there's outstanding SELinux integration issues with sysext...I will try to dig up a reference and see what we can do to get it fixed.

cgwalters commented 2 months ago

Also of course, what would make total sense is shipping dnf itself as a sysext, and then once merged it could itself generate further sysexts.

jan-kolarik commented 2 months ago

Hi Colin, sounds like an interesting idea. I’m just curious how it differs from the planned transient installation of packages using the bootc plugin, e.g., the dnf bootc install --transient foo command, which installs the package on an image-based system temporarily and then reverts to the previous state after a reboot. I know we’ve only discussed that in the context of dnf4 so far, but is this aiming for a different use case or user experience, or is it just another implementation of a similar behavior?

ppisar commented 2 months ago

If I understand it correctly, you want DNF to be able to create systemd-sysext https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html directories with the delta.

Do you have a documentation for the directory format? E.g. how one expresses that a file becomes removed after the installation?

From DNF point of view, there is one big problem: DNF does not manipulate files. DNF only commands RPM to install/uninstall RPM packages. All the file manipulation is done by librpm. One would first need to enhance librpm do produce the file system deltas.

cgwalters commented 2 months ago

Hi Colin, sounds like an interesting idea. I’m just curious how it differs from the planned transient installation of packages using the bootc plugin, e.g., the dnf bootc install --transient foo command, which installs the package on an image-based system temporarily and then reverts to the previous state after a reboot.

The bootc one is basically hardcoded to the bootc usroverlay path which mounts a transient overlayfs over /usr. It's not truly specific to bootc; one can trivially mount an equivalent overlayfs anywhere. The good and bad thing is basically that all of /usr becomes writable by everything, meaning you can just trivially cp /path/to/foo /usr/bin/someapp. But that's also bad; there's no concept of versioning for the overlay.

In contrast, the sysext approach is about much more controlled mutation; you need to write them to a look aside directory (or image) and then explicitly merge/unmerge.

One would first need to enhance librpm do produce the file system deltas.

Yeah you're probably right. I guess a bit more compatible way to do this would be to write to a temporary overlayfs over /usr in a private mountns, do the install, fixups like renaming the rpmdb, then take the overlayfs upperdir and copy it to the target sysext dir.