On Fri, May 22, 2026 at 2:52 PM Nicolas Chauvet via rpmfusion-developers < [email protected]> wrote:
> But the issue is that noarch stands for no specific architecture > dependencies. RPM doesn't have a concept for "all/fat arches" > packages. So my point is that having the package arched is a better > approximation than having it noarch given that we still need to > describe specific arched dependencies. In Fedora (and RPM Fusion), > noarch packages are exactly the same across all arched repositories so > if they become different, this --will-- break hard at build time. > There is no way around. > It's not clear how the initial setup will be once they will enable aarch64 (if they ever will) for generic distributions. Whether it will be inside the same tarball (likely), directly using the c3rt runtime (so no more i686 libraries required?) or if if will just be a depot for the Steam Frame with its own complete logic. At the moment FEX is not consumed by the host but is shipped in proton and I don't know how it will be shipped for the Steam Frame. Probably bundled with the client? Otherwise how do you use the overaly in i686 games? Also, DNF refuses to switch from i686 to x86_64 regardles of Provides/Obsoeletes and what not, so the process would be anyway to go from i686 to noarch to x86_64. This means we can look at this later whenever we know something more. There's no need to make it x86_64 now. The only thing is maybe adding ExclusiveArch x86_64 so it gets excluded from aarch64 for now. -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/
_______________________________________________ rpmfusion-developers mailing list -- [email protected] To unsubscribe send an email to [email protected]
