For ease of maintaining, it might be better to use the system-wide versions of the runners and contribute patches upstream for what is needed for Lutris.
Forking emulators leads to using extremely old versions. For example, according to the Github, the Dolphin branch is already 1000+ commits behind. Dolphin progresses very quickly, so a dev would have to spend time every few weeks/days to merge the commits, which would then require the users to update their runners.
A few commits in Dolphin can make a world of difference, as can be seen in their monthly updates. As such, those 1000+ commits might be the difference between a game running perfectly at 60fps and not running at all, really.
Of course, Dolphin is only an example. But the fact is that this way, you are maintaining X different projects, where X represents the number of runners you’ve forked.
It ultimately takes time away from developing the client and website 
If some specific things are required (Launch from command line, etc), we should probably send a patch upstream to add that functionality.
I haven’t looked at the code yet to see how Lutris handles finding the executable for runners yet, but we could use something like shutil.which() to find if a particular software is installed, then use that.
That would leave updating things in the hands of the user (Eventually, we could check against which version is installed if a script needs a particular version) and ensure that emulators are the most up to date possible.
1 Like
If you have a look here: Runners there was a similar discussion about using current/dev build runners. @strider said he’ll introduce the ability to use your own runners in a future update
1 Like
There are a few things that need clarification. First we haven’t forked all the emulators we ship. The only 2 forks we are using are o2em and osmose because they are unmaintained upstream (and as such I wouldn’t even call them forks, I’ve just taken over the projects).
Also, using system wide installed runners was the default behavior a couple years ago, we’re not reverting that decision any time soon. While it’s true that some runners lag behind upstream, generally speaking we offer version much more up to date than most distributions (all runners were updated at the end of 2015).
As an example, when a new version of wine is released, it is generally available before WineHQ’s PPA.
But the goal of doing this is not so much having the latest version, it’s having a set of programs we can rely on. Lutris is supposed to run on every Linux distro and we can’t assume that every emulator is available everywhere (because they are not). I’ve seen emulators deleted from the Debian archives for no good reason while others require a PPA (if the user is using Ubuntu) or manual compilation.
All our builds are semi-automated, which is not ideal because I’d like the system to be fully automated. I currently have to check for new versions, fire up my buildbot containers and launch a script. All these scripts are available here https://github.com/lutris/buildbot/tree/master/runners and they use upstream code for the most part. Ideally, I’d like these containers to be running on lutris’ server with a simple Web UI to launch builds (the fact that runners are not automatically updated on the client also needs to be addressed). Issues can be created on the buildbot repo for out of date emulators, I’ll relaunch a build, the process is really simple.
However, it is planned to let users set custom runner executables in a future version, in the same way we do for Wine. That would let lutris users use their system wide installed emulators.
As far as patches go, I managed to get one in Dolphin to make the emulator run from any location and I’m currently trying to get SDL2 support into PCSX-R so, yes, I’m already all in favor of sending patches upstream 
1 Like
Fair enough 
Having a set version to rely on is indeed a good thing for the end-user as far as ease of use goes. And being able to set your own executable for a particular runner would fix what I talked about for users that do want to have the most recent version for whatever reason.
Sorry for the assumptions, I’m still learning how the project is organized 
I have a few UI things I’d like to work on in the future, when I’m more familiar with the project 
And maybe more afterwards as I get more familiar with the code base and hone my skill.