Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
@dmnks Next time shout at me about what's missing! I Would have been happy to discuss improvements to mkosi to make it work for your use case. (I would have commented but had no clue you were considering it) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-2000416984 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Closed #2643 as completed via #2733. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#event-10820445930 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Yep, thanks. I noticed this too on Hacker News yesterday and was almost going to post the same here :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1736872845 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Well, apparently this is now a thing: https://macoscontainers.org/ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1736575490 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> > None of this is inherently Linux specific, however to make it reasonably > > fast and efficient, you need something like OverlayFS which is currently > > only available on Linux (and [#2559 > > (comment)](https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921) > > on some BSDs through fuse-overlayfs but that's likely slower than a native > > kernel implementation). > > [FUSE exists on macOS too](https://osxfuse.github.io/), though I don't know > if `fuse-overlayfs` works with it. Oh, nice. Also, see: https://github.com/containers/fuse-overlayfs/issues/140 But again, not something I'm going to invest time into. Anyone interested, feel free to investigate and/or submit patches ;) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719487211 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> I will also point out there are openSUSE containers that use DNF too. Interesting, thanks for sharing. I don't think it changes anything discussed here so far, though :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719476441 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> None of this is inherently Linux specific, however to make it reasonably fast > and efficient, you need something like OverlayFS which is currently only > available on Linux (and > https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921 > on some BSDs through fuse-overlayfs but that's likely slower than a native > kernel implementation). [FUSE exists on macOS too](https://osxfuse.github.io/), though I don't know if `fuse-overlayfs` works with it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719473973 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
One more thing to add to the above: *This* ticket is about using OCI images for the test root creation, on Linux distributions. Any kind of non-Linux work would need to be tracked in a separate ticket. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719473050 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> Keep in mind, we need a way to run it directly on the host, because all this > fanciness you're talking about doesn't exist on non-Linux platforms. In > particular, I would like to be able to run the test suite for RPM on macOS > still. In essence, what the test-suite needs is a filesystem tree that contains an installation of RPM to test and its runtime dependencies (i.e. a `make install` as root in a development VM would do just fine), and a way to quickly make writable copies (e.g. copy-on-write snapshots) of that tree. Then, a plain chroot into those snapshots could be used to isolate the individual tests. None of this is inherently Linux specific, however to make it reasonably fast and efficient, you need something like OverlayFS which is currently only available on Linux (and [reportedly](https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921) on some BSDs through fuse-overlayfs but that's likely slower than a native kernel implementation). And then, instead of chroot, we *want* to (and *do*) make use of containers in our tests, now that we've freed ourselves from fakechroot. They offer much more possibilities, including proper uid/gid mapping for file ownership testing, unsharing more than just the filesystem namespace, etc. One way to make the test-suite POSIX compatible would be to identify tests that *require* a proper container and disable those on platforms that don't have containers. There, chroot could be used instead. But I'm not sure if we really want to go in that direction. Even then, while chroot is available on most UNIX platforms, OverlayFS-like functionality is not, or varies greatly among the systems (APFS on macOS comes close perhaps) and would need special handling. This really is not something we (the core development team at Red Hat) have the resources and/or expertise to cover. We rely on the community to do this work. One thing that's *not* mandatory, though, is rootless operation. We can always just assume that the test-suite is run in a development/throwaway VM. That's one less thing to worry about when it comes to supporting non-Linux systems. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719466788 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
I will also point out there are openSUSE containers that use DNF too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1718407495 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Keep in mind, we need a way to run it directly on the host, because all this fanciness you're talking about doesn't exist on non-Linux platforms. In particular, I would like to be able to run the test suite for RPM on macOS still. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1718407103 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Oh, that's a nice bonus. Assuming of course it actually works :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1715127114 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Oh, Ubuntu 22.04 LTS (our lowest common denominator) ships Podman in the official repos. Nice. We can then drop Docker support altogether and just use the same backend for local and CI purposes. Most likely (still need to verify that the Podman version in Ubuntu works the same way). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1714124410 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> 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). Oh, this is actually a very good point. It's not something I had in mind previously, but it's yet another reason to just reuse the same Dockerfile image for both building and testing, indeed :smile: (which is in line with the planned solution of this ticket). > Edit: I remember now (after re-reading some of the commentary in this > ticket): the mktree.fedora case was needed to allow testing the locally built > binary against that distro version, whereas the CI case is different. That > was how and why it was so special. I'll just stock on some popcorn and sit > back to see what happens in this space Ack, yes, that's the thing. We want both portability and integration with a local build for native development. And yup, popcorn is in order, indeed :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1713783267 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> 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. 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-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> Actually, adding `dbus-libs` to the Dockerfile wasn't needed because it > already contains it It gets pulled in as a dependency of `dbus-devel` which > we install there in order to build RPM (it's not needed in `mktree.fedora` > obviously). 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. :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. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1713640056 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Anyway. Having slept on this a couple of times, it's become clear that we just don't want to deal with all this bootstrapping business and basically re-implement `mkosi` (which we can't use for other reasons as outlined above). So, circling back to where we started, all we really need is to outsource the base image creation to OCI and be done with it. That means, option 2 from the [comment above](https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1710226738) is what I'm going to implement. Thanks for your attention :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1711739452 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Ah, OK, I think this is the error I saw initially (and now too): ``` error: unpacking of archive failed on file /dev: cpio: chown failed - Device or resource busy error: filesystem-84.87-12.1.i586: install failed ( 4/27) Installing: filesystem-84.87-12.1.i586 .[error] Installation of filesystem-84.87-12.1.i586 failed: Error: Subprocess failed. Error: RPM failed: Command exited with status 1. ``` It's still possible to select "ignore" in the prompt and continue without any further errors, though. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1711615539 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> ## Problem > > It turns out that, while this is quite easy to do on Fedora with DNF and > `unshare(1)`, it is not as easy on other distros that I've tried, namely > OpenSUSE where Zypper doesn't seem to like being run through `unshare(1)`, > and would likely require `sudo` instead Hmm, not sure what I did wrong when trying this out originally, but now I've just tried doing an `unshare -rm --mapauto zypper --root ...` and it seemed to work just fine and installed the filesystem into the specified directory. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1711613259 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
In terms of usefulness/viability, the worst is option 3, followed by option 2 and then 1. Basically, the biggest drawbacks of 2) and 3) are in the area of local development with `make shell` and `make env`. These are new features that weren't there before the recent test-suite rework, so making them worse wouldn't be the end of the world. However, these features also *are* some of the niceties that the test-suite rework has allowed for, and throwing them away would be a pity. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1710252604 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
To summarize again, these are our options to resolve the ticket: ### 1) No change, keep the native & podman backends Image building: * Done by a host specific script, typically with a native package manager (DNF/Zypper/...) Container layering: * Host and per-test isolation is done with Bubblewrap & OverlayFS Pros: * Iterative `make shell` development, without needing to throw the container away on each rebuild * Ability to reuse the same DNF/Zypper/... wrapper for managing software in the test tree in `make env` * Pristine image with no pre-existing RPM artifacts or unwanted software * Separate backends optimized for different use cases (native development vs. portability) Cons: * Possibly more maintenance due to the use of the native package manager * More complicated to support other hosts natively (e.g. OpenSUSE) ### 2) Use an OCI base image Image building: * Done by Podman/Docker using a host specific Dockerfile Container layering: * Host and per-test isolation is done with Bubblewrap & OverlayFS Pros: * Standard base image format * Easier to support other hosts Cons: * Less convenient `make env` (no host specific package manager wrapper, needs manual use, e.g. `dnf --installroot=$RPMTEST` works but is not optimal, needs more options for local cache reuse or to suppress warnings, all of which is part of `mktree.fedora` already) * Less control over the base image (still tweakable through the Dockerfile but more work) * Additional dependency on the host (Podman/Docker) ### 3) Use OCI for full image & container management Image building: * Done by Podman/Docker using a host specific Dockerfile Container layering: * Host isolation is done by Podman/Docker natively (`podman run`) * Per-test isolation is done with Bubblewrap & OverlayFS Pros: * Single dependency on the host (Podman or Docker) * Same stack locally and in CI Cons: * Less convenient and more complex `make env` (mounting `$RPMTEST` would require a different containerization stack than what's used in the test-suite) * Much less useful `make shell` (user changes to the container are dropped on each RPM rebuild) * Docker is missing a lot features, e.g. no equivalent for `podman image mount` or `podman unshare` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1710226738 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
One way to fix *that* would be to simply build and test with the `mktree.fedora` backend even in the CI, but from a Fedora container, due to the build deps. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1709969191 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
And yes, that's still double-maintenance in a sense, but it's due to the fact that we do *not* need build deps of RPM in the local testing scenario, as those are installed on the host (RPM is built on the host). So, not really much of a problem. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1709967448 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> The other important point here is to avoid tests behaving differently locally > and in CI (AIUI CI didn't need the dbus-libs tweak in > [4712c9c](https://github.com/rpm-software-management/rpm/commit/4712c9c37bbf28f56f1e386df788dac440cc4cb8) > but local usage does, and that's unwanted double-maintenance if nothing else) Actually, adding `dbus-libs` to the Dockerfile wasn't needed because it already contains it :smile: It gets pulled in as a dependency of `dbus-devel` which we install there in order to build RPM (it's not needed in `mktree.fedora` obviously). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1709962928 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
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-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Ack, it's a confirmed *bug* now and will be dealt with like any other. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1706551024 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Yep, to me that'd be among the top issues to address. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1706548969 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
Yup, just the fact that we currently have *two* distinct ways to create a test image is awkward and just attracts all kinds of bugs :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1706543839 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> So, to summarize, the goal of this ticket is to merge mktree.fedora and > mktree.podman such that a host-specific Dockerfile. is used to build > the image, instead of a mktree. script that does that from scratch. > It also has to support reusing the local build artifacts for local > development. > > This way, we'll delegate the image creation process to the appropriate > tooling where it really belongs. We'll only need to keep a (bunch of) > Dockerfiles which are well-defined and easy to maintain. :+1: to this from a high-level viewpoint, the Dockerfile is widely understood, lets not reinvent a wheel we don't have to. The other important point here is to avoid tests behaving differently locally and in CI (AIUI CI didn't need the dbus-libs tweak in 4712c9c37bbf28f56f1e386df788dac440cc4cb8, local usage does) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1706477609 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
