Oh, I'd missed your comment @DaanDeMeyer, sorry!
Yep, I indeed *did* consider mkosi initially and even had a branch where I
played with it for a couple of weeks. However, later I realized the philosophy
of mkosi wasn't completely in line with our requirements (and that's OK!),
which were:
1. Reuse the local, native cmake build directory and install those artifacts
into the target image, instead of doing a separate build on the side (like
`mkosi build` does). Basically, we want the test-suite to exercise the user's
build directory (that they'd have anyway) rather than keeping an additional one
on the side.
2. Allow for cross-building images (e.g. build a Fedora image on an Ubuntu
host). This is of course the core feature of mkosi, however it requires a
reasonably recent OS version (and/or mkosi) on the host, as well as a
reasonably recent package manager of the OS you're targeting. This is a hard
requirement for us because we need to run the test-suite in a CI environment
where we can't control the host/VM OS selection. Currently, we use GitHub
Actions which only has Ubuntu 22.04 LTS. And building a target image based on
Ubuntu wouldn't work for us either because Ubuntu isn't RPM's main target
platform and thus doesn't have the latest dependencies.
3. Rootless image building. I know this is already supported in mkosi for a
while but it wasn't when I was considering it (so it was another factor).
So it eventually turned out that using OCI images was the best solution for us.
The tooling is ubiquitous and already preinstalled on the Ubuntu VMs in the CI
(as well as typical developer systems).
In retrospect, though, I would've talked to you, indeed, if just to understand
the whole landscape where mkosi operates better. There certainly are nice
features in mkosi that we could use, OTOH right now we're happy with the OCI
setup and wouldn't gain much (if anything) by switching.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-2127616052
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2643/2127616...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
