Request: Support for native games

[Kreyren]

Requesting native games support on phoenicis for reasons in:

@ImperatorS79 No need to use wine.

Since you need to download dependencies for lots of games that runs natively on linux -> Phoenicis can handle that better expecially when those games doesn't work on deps provided by distro like opsu on fedora that outputs:

OpenJDK 64-Bit Server VM warning: You have loaded library /home/jamespark/Games/osu/Natives/liblwjgl.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.

witch which fedorans doesn't know what to do.

--

Or other games that needs older version of deps that user don't neccesary want to install.

--

it would expand phoenici's usecase since games would be one click with required deps or methods like decising if you want to play windows version of OSU using WINE or native, etc..

Curent is that if you want to install a game -> you need to debug it.

Originally posted by @Kreyren in https://github.com/PhoenicisOrg/scripts/pull/897#issuecomment-472792104

[plata]

I can understand the reasoning behind this. I'm not sure if this is the direction we want to go, though. If you think about it, there's no need to restrict this to games. So we would need to support all possible native applications. While this might (maybe) be possible for Java applications etc. It's certainly not for C/C++ applications. So in the end, we would basically turn Phoenicis into a Linux distribution and this is certainly not our goal.

[Kreyren]

So we would need to support all possible native applications.

Those are supported by distro no need to support them in phoenicis

I want phoenicis to be usable instead of steam loaded with all games that are running on linux, windows and consoles..

[madoar]

@plata isn't it quite easy to support native applications (i.e. scripts targeting native applications)? We just need to execute the correct console commands, right? The main issue will be to support multiple operating systems with one script I believe.

[plata]

@madoar I don't think that's enough because:

1. An application might not be available on all distributions. So instead of the OSs LINUX and OSX, we would need every possible distribution and someone would have to maintain that.
2. Even if an application can be installed, it's not trivial to know how it can be started.

So, if you want to provide native applications, this cannot be done in a general way (like you said). Of course, you could make a repository "native Ubuntu 18.10 apps for Phoenicis" but I really don't see the point of this.

[madoar]

I don't think we need to support all linux applications. We just need to support applications from certain sources, like:

• linux wine
• source code
• jar files

The interesting aspect in supporting linux applications from Phoenicis is that we can specify how they should be accessed from the system. For example for jar files we can specify program arguments and create shortcuts, which make it much more intuitive to execute java applications in my opinion.

[plata]

I'm not convinced really: For example for jar. This might require to bundle several JREs.

[madoar]

Yes, but that doesn't need to be part of Phoenicis. I think we just need to provide a way to install the application, to start it and to uninstall it.

[plata]

If it's not part of Phoenicis, the app will not start (unless the app bundles the JRE itself of course). Why should someone bundle a JRE if they are not even able to provide a proper .desktop file?

[Kreyren]

Provide deps too then like lutris is doing

[madoar]

I don't know. This stuff (e.g. does a JRE need to be installed separately) should be encapsulated by a new Engine implementation.

[plata]

You're right. That could work indeed for Java applications. For other types (really native applications), I still can't see it.

[Kreyren]

For other types (really native applications), I still can't see it.

Depending on the deps for example for vulkan we can make phoenicis to perform sanity check and to ensure that vulkan is supported if end-user tries to play game that depends on vulkan -> outputs error message if not supported and asks for installation.

[plata]

@Kreyren it's not that easy. If you compile a C++ application in one system, it might simply not work in a different one. If you try to enable that, you will end up with flatpak/snap...

[Kreyren]

@plata Just to clarify: If vulkan is not usable -> output error

You dont need to do anything else for vulkan since it's impractical to provide packages and drivers. For other apps depends.. outputing error message is sufficient fix for now to allow compatibility.

[plata]

I don't care about vulkan if the application does not even start... This doesn't necessarily depend on "special" stuff like vulkan. It can happen anyways (in fact, it's quite likely that it actually will happen).

[Kreyren]

I don't care about vulkan if the application does not even start... This doesn't necessarily depend on "special" stuff like vulkan. It can happen anyways (in fact, it's quite likely that it actually will happen).

i dont understand the scenario

[plata]

This would lead too far here but if you're interested, you can search on the Internet for the reasons why flatpak/snap has been introduced and why it has advantages over "simply" providing deb/rpm etc.

[Kreyren]

make it brief then.. and even if i see no reason to limit phoenicis development due flatpaks incompetence.

[madoar]

I'm always open for supporting new types of software for Phoenicis. Every type of software should require its own Engine type. I think that implementing the Engine for a new software type is the biggest challenge.

Summarized I see no problem with supporting native applications for Phoenicis, but I don't think that this should be part of Phoenicis itself. Instead native application support should be provided via scripts (like wine applications).

[plata]

Not possible really. And if you think there's a "flatpak incompetence", you must have completely misunderstood my point.

[plata]

@madoar we should split this to several issues. Can you open one for JRE and for everything else you think is feasible separately?

[madoar]

I've just opened #900 and #901. Please be aware that these are just some ideas of mine. They are not fully thought through yet and may even be unfeasible at all.

[ImperatorS79]

I do not think phoenicis should provide "engines" for native apps. What you could think of is to provide a shortcut for games you have on your computer (native from .deb, from Steam (native), from Steam (steamplay)), so that you can access all of them from the same interface. There is no real need for script installation for native apps (they generally all come as .deb, flatpak, snap whatever). Why would you use a intermediate apps to launch apps you can directly launch from the OS ?

[Kreyren]

@ImperatorS79 > Why would you use a intermediate apps to launch apps you can directly launch from the OS ?

Because running native directly is not always an option + it's faster to press one button instead of spending 8 mins average to get one game working

[ImperatorS79]

Because running native directly is not always an option + it's faster to press one button instead of spending 8 mins average to get one game working

If it is native by definition it is works. If you download games/apps from distribution repo, or steam, or steamplay, you will never encounter this. The use case is then limited to unpackaged apps than do no provide required deps to work. I find this really limited to spend time on.

[Kreyren]

If it is native by definition it is works.

Yes, but this is linux full of distros that limits funtionality.. Like EndlessOS that depends on phoenicis to provide wine and make games working on it..

If you download games/apps from distribution repo, or steam, or steamplay, you will never encounter this. The use case is then limited to unpackaged apps than do no provide required deps to work.

You will.. There is lots of variables that you can't affect directly -> providing container with required deps is preffered by a lots of ppl just look at lutris it has lots of bugs but ppl rather press one button then installing it from source on some distros.

In theory provide two methods

• Provide container
• Install native game

I find this really limited to spend time on.

elaborate

[ImperatorS79]

providing container with required deps is preffered by a lots of ppl

I still do not see your point. We are talking about native apps. How much native apps exist without proper package?

You will.. There is lots of variables that you can't affect directly

Which ones?

Install native game

How much native games are not available from Steam or from proper packaging ?

[plata]

@Kreyren like I said, the use case you describe here (container with required dependencies) can be implemented in a much nicer way by providing a flatpak/snap.

Java applications are an edge case which might make sense but everything else (really native applications) not.

[Kreyren]

by providing a flatpak/snap.

That is not always an option.. Just look at winepaks they are not usable..

Java applications are an edge case which might make sense but everything else (really native applications) not.

Expected one click in phoenicis -> Play native games.

[plata]

Superseded by: #900 and #901.