On Thu, Jun 26, 2025 at 11:07:11AM -0400, Solomon Peachy wrote: > On Thu, Jun 26, 2025 at 03:46:44PM +0100, Daniel P. Berrangé wrote: > > > Question: How are said containers to be constructed (much less > > > maintained) when working within the Fedora/RHEL ecosystem? > > > > Thanks to Debian multi-arch it is possible to build cross envs for > > many archs, from any Linux system with podman/docker. This gets > [...] > > That's probably way more info than you wanted :-) > > While that's a ton of information, it didn't actually answer my > question. But after looking at: > > https://gitlab.com/libvirt/libvirt/-/tree/master/ci/containers > > ..it appears that the answer to my question is actually "i686 containers > will need to be constructed and maintained from the Debian ecosystem > instead of Fedora/RHEL" > > Will that still work for foundational hardware-interacting things like > Mesa? I mean, you're all but guaranteed to have different major > versions on the host system (eg Fedora's v25.x actively driving the > desktop) vs what's in the container (eg v24.x in the Debian-derived i686 > container that gets invoked to run $game)
Ah so my comments were directly in context of the concerns upthread about use of Fedora as a platform for GCC maint. I think the containers approach I outline, is a good solution for most day-to-day software dev tasks that need to test cross-arch builds, and to a lesser exttent basic unit testing. I was NOT suggesting that we should promote Debian ecosystem as a way to host steam / other games requirements, ie end user runtime usage. I don't know much about Mesa myself, but what I've read in this debate, it would be highly preferrable to have matching versions of mesa between i386 and native x86_64 host. So if we want to retain an i386 capability for runtime usage, my suggestion (mentioned earlier in this thread) is to explore the provision of cross-compiled i386 libraries on Fedora, in the same approach we use for Mingw32/64 in Fedora which has been pretty successful over the years, with its maint burden confined to just the packages that are relevant. NB, there are two ways we do mingw - the legacy approach was to have separate source RPMs for mingw but the modern preferred approach is sub-RPM builds from the native package. While the latter puts a bit of extra burden on the native package maintainer, in many cases this was the same person who was already doing mingw builds, and it avoids the pain of keeping versions in sync. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
