[Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)

[Michal Domonkos]

> Oh but it wasn't added to the Dockerfile but mktree.fedora, where on that third (?) level of inception dbus-devel is _not_ installed because that's just rpm's own build-dependency whereas mktree.fedora prepares an environment for just the test-suite. 😄

Yup, I can see how this is confusing, and that's one of the reasons I want to simplify this, by only having *one* way of creating the image.

Nevertheless, the idea of a mktree.<distro> script was to bootstrap an image with *only* the runtime and test deps, since the build deps are irrelevant to the test-suite. That's why you needed to add dbus-libs explicitly to the DNF command line there.

The Dockerfile (and mktree.podman) only existed as a universally portable variant of the above which also *builds* RPM in a container. And, as an optimization, it *reuses* the same image for the testing too, instead of setting up a separate tree with mktree.fedora afterwards, because the Dockerfile is based on Fedora and thus already contains the runtime deps for RPM :smile: 

> One could also look at that from the point of separating rpm's build-requires and test-requires, but it doesn't seem meaningful. We'll want to be able to do stuff like use cmake to compile something against rpm in the test-suite (but that's yet another story). The test-environment equaling the build-environment seems the path of least maintenance. As with the current CI environment, AIUI. OTOH I could also be utterly confused 🤪 😄

Confused perhaps (can't blame you, lol), but also on point. Indeed, our goal is to *equal* the build and test environment in terms of the underlying libraries being ABI compatible (i.e. you build for library 1.X.Y and you run with library 1.X.Y), but not necessarily in terms of the actual root filesystem.

The simplest way to do this is `sudo make install` and then `sudo ./rpmtests`. But we don't want to force the poor developer to dump their RPM snapshot into their workstation system (and to risk getting their files purged on a forgotten "rm -rf" somewhere in the test-suite) so we separate the test environment through containerization :smile: 

Slightly off-topic:

One way to avoid the image management altogether would be to simply reuse the root filesystem on the host as the lowerdir in OverlayFS terms. However, for that, one needs real root privileges. Plus, we wouldn't have full control over that test environment since there could be random stuff installed on the host and possibly interfere with the tests and/or cause weird failures.

Another way would be to reflink the necessary libraries from the host. That would be limited by the filesystem in use, e.g. btrfs or xfs support that but ext doesn't. Also, we would have to somehow obtain the files to reflink, which could possibly be done with something like `rpm -ql libfoo`, however that still would not guarantee a 1:1 copy of the given package since there are scriptlets which wouldn't be run. If we added a feature to RPM to "clone" or "rebase" a package to a different root filesystem, that could be used :smile: But that's really not something to worry about *now*.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1713774012
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/2643/1713774012 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230911/22dc4f37/attachment.html>