Closed toto621-linux closed 2 years ago
liberodark
commented
2 years ago Hi,
That a bad idea... All patch is applied when the compilation is make on batocera. Flatpak is build only for pc without optimisation or fix for batocera. Remember batocera is retrogaming system and need specific attention & patch.
toto621-linux
commented
2 years ago @liberodark But you already did it for steam right ? and current Yuzu implementation in just appimage renamed so basically a flatpak alternative. I also tried rpcs3 and it work better with flatpak than current batocera's version because it's up-2-date version.
Beside that proton and lutris are just standard version (unless I missed something) and I even added proton-ge without problem by simply downloading official release. Retroarch/libretro cores I don't know i must admit you probably talk about this one (huge one).
I talk only for x86_64 build only of course.
I don't see the issue with providing a solid base system and rely on flatpak for most emulators (up-2-date, easy to install, ect...) but I'm no expert so if you say so then so be it :)
Fishaphrodite
commented
2 years ago Steam, as far as I can tell, cannot be compiled by people, and was added as a separate system due to the demand for it I believe, meanwhile most emulators in batocera can be built fro msource, that means they can be patched as well if needed, while a flatpak cannot (not from the end file I mean), also, when updating a flatpak, you are updating a completely external program that makes no guarantee to be batocera compatible, or to not break stuff.
Current Yuzu implementation is not supported as well, and if it was, I suspect it would not be an appimage.
To me it feels outside the scope of batocera (which is normally to build as much stuff as possible from source, and adapt it if need be, while having a easy config; while that approach makes it more like an end-user pulling programs in, and making their own scripts for it), flatpak also wouldn't work for every system, which means separating even more the current images available one from another. The up-to-date issue isn't an issue with how the implementation works, it just takes time.
If anything, retroarch cores would actually be the less tricky part, as they are often just a .so file to be loaded, but even then, here they are built from source as well.
toto621-linux
commented
2 years ago @Fishaphrodite It not out of the scope when it allow faster and more often updates for stuff like emulator which need tons of versions to be "stable" so if you stuck with poor version of emu in batocera you're basically stuck for months.
For older stuff (anything older than PS2) it's not be a problem to not use latest version of emulators but for post-PS2 era it's mandatory since every few days many patches and fixes are made (look at RPCS3/Yuzu with nerly every day build, Cemu every 2 weeks)
Anyway, as long as batocera's team will support flatpak, I will be ok with it since I can then install and use updated stuff myself (mainly RPCS3 and Yuzu but I tried PCSX2/Flycast/ect... and they all work flawlessly) without relying on beta and all the bugs that goes with it.
I understand what batocera's team is trying to do : ES is for beginers that just want out-of-the-box but old stuff (perfect for old/poor hardware), advanced users can go with flatpak and enjoy updated material (good for more powerfull hardware), it's a win-win situation in the end, not perfect but at least it's exist.
ghost
commented
2 years ago Hi,
That a bad idea... All patch is applied when the compilation is make on batocera. Flatpak is build only for pc without optimisation or fix for batocera. Remember batocera is retrogaming system and need specific attention & patch.
Flatpak exists for other architectures as well, and would potentially be the only way to get Brutal Doom running on the Pi4 with Batocera as we can already do in RetroPie/Raspbian builds. And as long as Flatpak is sandboxed it should not impact the rest of Batocera. Non-PC users would of course not be able to use the GUI to install Flatpak outside PC but they could still use the CLI.
flatpak remote-info flathub org.zdoom.GZDoom/aarch64/stable
ID: org.zdoom.GZDoom
Ref: app/org.zdoom.GZDoom/aarch64/stable
Arch: aarch64
Branch: stable
Collection: org.flathub.Stable
Download: 23.6 MB
Installed: 37.5 MB
Runtime: org.freedesktop.Platform/aarch64/21.08
Sdk: org.freedesktop.Sdk/aarch64/21.08
Commit: fdf6a4325de8afba2b2c01baad7f0a9a90e31b7caccdb0fec592be6953d275da
Parent: 4c38d3a658b2871d97eca4c1333cb6b8e44aa84f74c724cd94d1d757a61d7c33
Subject: Update GZDoom to 4.7.1 (f1187351)
Date: 2021-10-20 20:13:15 +0000
Since flatpak packages are always up-2-date and, after making modifications to fully integrate them in ES, will be far easier to manage/update, why not using flatpak as base for :
It would be easier for batocera's team and end-users like this. I dont know how much work it require to modify ES to integrate thoses changes but it's a viable option for the future I think as batocera's team will only have to focus on a rock solid base system and let flatpak's mainteners do the rest (just my 2 cents)