Le ven. 22 mai 2026 à 08:46, Simone Caronni via rpmfusion-developers
<[email protected]> a écrit :
>
>
>
> On Thu, May 21, 2026 at 6:24 PM Gary Buhrmaster via rpmfusion-developers
> <[email protected]> wrote:
>>
>> I have this (very) old memory that changing from arch'ed
>> packages to noarch (or vice versa) did not always work
>> correctly (without epoch'izing?). That may have been well
>> over a decade ago with yum, so it might no longer be
>> relevant (and as the steam package, as I recall, is mostly
>> just installing a script that downloads the full payload, it
>> probably does not matter, as it never installed files into
>> isa dependent locations).
>
>
> The issue is only with switching architectures (ex. trying to go from i686 to
> x86_64) but not going to noarch or going away from it. So the upgrade in this
> case is successful.
>
>>
>> However, since the current requirements can only be
>> satisfied on certain platforms today, should the spec file
>> not include ExclusiveArch modifiers today (which can
>> be adjusted if/when those other enhancements are
>> enabled by valve?)
>
>
> I will make a test, it would mean for now to have both of these:
>
> BuildArch noarch
> ExclusiveArch x86_64 i686
Thanks for the explanation.
That can be the way forward (should work with koji/mash), especially
when the aarch64 arch will be added.
That said noarch means the package will be the same with all
architectures, so you aren't supposed to emit any arched dependency
from noarch package.
It currently works in x86 context because x86_64 can satisfy the
(x86-32) %{_isa} dependency, but it won't work when aarch64 will be
introduced.
The only issue I know related to arch package migration is that
sub-packages for noarch packages cannot be arched,
while arched packages can have noarch sub-packages.
So I think it might be easier to move to ExclusiveArch: x86_64
(aarch64 when relevant) instead, even if the content is the same. It
will be an easier spec file to read when arches conditions can be
added.
That said, I think the future will be to have 32bit games using the
proton/wine WOW64 layer, so even win32 games can use x86_64 linux
binaries. I think that native linux games, if 32bit x86, will be
phased out.
This should drop any 32bit x86 dependencies allowing steam to be
generally usable on rhel10 (among others goals).
We could still have a compatibility sub-package adding these
dependencies (as previously done).
_______________________________________________
rpmfusion-developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
