Add retroarch for 32bit architecture

[davidhedlund]

Proposed x86 package names

Suggested packaged names for x86 AppImages from https://buildbot.libretro.com/ :

• retroarch-x86
• retroarch-qt-x86
• retroarch-nightly-x86 - https://buildbot.libretro.com/nightly/linux/x86/RetroArch.7z
• retroarch-qt-nightly-x86 - https://buildbot.libretro.com/nightly/linux/x86/RetroArch_Qt.7z

Code for x86_64 RetroArch AppImages can be reused.

This will complement:

• retroarch, retroarch-qt, retroarch-nightly, retroarch-qt-nightly #2255

Thank you very much for your endless efforts on AM and for continuously improving the project! 🙏🐉

[ivan-hc]

AM already supports 32 bit applications, the architecture is also known as i686:

• https://github.com/ivan-hc/AM/tree/main/programs/i686
• https://github.com/ivan-hc/AM/blob/main/programs/i686-apps

But I plan to move such architecture to a third-party database for AM

https://github.com/ivan-hc/am-extras

Almost all distributions have already abandoned the support.

[ivan-hc]

Almost all distributions have already abandoned the support.

This is why I said in your request for RetroArch that I plan to remove i686 scripts from the AM database.

[ivan-hc]

@davidhedlund to not repeat myself #2255 (comment)

[davidhedlund]

@davidhedlund to not repeat myself #2255 (comment)

AM already supports 32 bit applications, the architecture is also known as i686:

* https://github.com/ivan-hc/AM/tree/main/programs/i686

* https://github.com/ivan-hc/AM/blob/main/programs/i686-apps

But I plan to move such architecture to a third-party database for AM

https://github.com/ivan-hc/am-extras

Thank you for quick response!

So, are you going to add these packages to the third-party database, or not?

• retroarch-x86
• retroarch-qt-x86
• retroarch-nightly-x86
• retroarch-qt-nightly-x86

[ivan-hc]

Done, although I don't think it was worth it.

[ivan-hc]

So, are you going to add these packages to the third-party database, or not?

It's still too early to study a third-party database. Furthermore, the fact that it's a portable app and not an AppImage complicates things for that purpose.

[davidhedlund]

So, are you going to add these packages to the third-party database, or not?

It's still too early to study a third-party database. Furthermore, the fact that it's a portable app and not an AppImage complicates things for that purpose.

Thank you.

[davidhedlund]

Done, although I don't think it was worth it.

Shouldn't this issue be closed as "Not planned"?

[ivan-hc]

Done, although I don't think it was worth it.

Shouldn't this issue be closed as "Not planned"?

But I just solved it!

9b4eb5c

[davidhedlund]

Done, although I don't think it was worth it.

Oh, sorry—I misread it as 'Done [closing, because], I don't think it was worth it,' since the first message lacked a commit reference URL.

So thanks a lot! I referenced this issue in libretro/docs#1135