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

[Michal Domonkos]

I've come to realize that, by losing host-specific mktree scripts (e.g. `mktree.fedora`), we would also lose a couple of nice features along with it, namely:

#### 1) Ability to simplify test tree management with the host package manager

The recently added `make env` target runs a shell on the host which mounts a test tree at `$RPMTEST` that can be used in the same way as in a normal test, i.e. to run RPM in it with `runroot rpm` and to inspect/modify the filesystem with the host tooling.

This, quite conveniently, also applies to the software installation in the test tree. One can now use the host native package manager to extend the tree when doing interactive testing with `make env`. In fact, on Fedora, `make env` defines an alias which basically amounts to `dnf --installroot=$RPMTEST` to make this process easier. Coincidentally, the command is almost identical to the one needed to bootstrap the tree in the first place.

By contrast, the Dockerfile native way is flipped inside out. It assumes that software is installed from within the base image which ships with the native package manager from the start. However, that's not compatible with *our* needs since we're actually dealing with a component in the very same packaging stack.

Therefore, *separating* the management of the test tree from the actual testing makes more sense. It's also why the test logic has always run *outside* of the test tree, not inside of it.

So, by going full Podman/Docker for image management, we would lose the host-specific wrappers (DNF on Fedora) in `make env`. May not be a big deal, but a pity for sure.

#### 2) Full control over the test tree

By bootstrapping the tree from scratch, we can control what software goes into it without resorting to a "dnf remove" or "rpm -e --nodeps" in an equivalent Dockerfile. Most notably, as mentioned in the description above, this pertains to the RPM installation itself which we need to purge before installing the local one.

Furthermore, if we were to go even further and use Podman/Docker to also spawn the wrapping containers (i.e. `mktree.podman` being the default), we would also lose this in local development:

#### 3) Ability to swap out the RPM installation in a container

This is currently very useful in `make shell` and `make env` as it avoids the need to throw away your changes to the container each time you make a source change in RPM.

By using Podman/Docker to spawn the container, we would have to either `make install` the new artifacts over the ones already present in the container or rebuild the image, thus having to recreate the container too.

While the former (redo `make install`) may not be a problem in most cases, it certainly isn't as clean as simply recreating the installation directory from scratch, which is what we currently do in `mktree.fedora`.

The latter (rebuild the image on each change) would seriously hamper any useful container-based development.

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

Message ID: <rpm-software-management/rpm/issues/2643/1709630985 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230907/1925ada2/attachment.html>