(Config) Support multiple core directories

[orbea]

Is it possible that two core directories could be supported? One for for cores installed via the distro's package management tools and the other for those downloaded from the buildbot. This would be very helpful for those packaging RetroArch and the libretro cores for a specific distro.

For example in Slackware one of the usually preferred methods of installing software not provided in the Slackware base install is to compile it yourself and then install the package with the help of the scripts provided by pkgtools. So to make this work with RetroArch I edit the configuration file which will be installed to /etc/retroarch.cfg.

sed -e "s|# libretro_directory =|libretro_directory = /usr/lib${LIBDIRSUFFIX}/libretro|" \
       -e "s|# libretro_info_path =|libretro_info_path = /usr/lib${LIBDIRSUFFIX}/libretro/info|" \
       -i retroarch.cfg

This works great until someone decides they want to install a core through the RetroArch online updater instead where they probably do not have permissions to write to the default core directory as a normal user. However if I remove this then any of the cores that have been compiled on Slackware and installed via installpkg will not show up in the RetroArch ui.

I think the ideal solution would be to support both, a system core directory and an user's local core directory. The user's local core directory would take the place of the current upstream default while the system core directory would be left optional for package maintainers. In the event the same core is installed by both methods then there should be a simple way to tell them apart in the ui when selecting a core.

For reference here are the current RetroArch and libretro slackbuilds. https://notabug.org/orbea/SlackBuilds-git/src/master/games/libretro https://notabug.org/orbea/SlackBuilds-git/src/master/games/RetroArch https://notabug.org/orbea/Slackbuilds/src/master/games/RetroArch

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/36110443-feature-request-support-two-core-directories?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github).

[LaserMoai]

Wouldn't updating cores automatically be a bad idea in most cases since emulator savestates are almost always only compatible with the version they were created with? Just a thought. EDIT: This would be a much more convenient update system improvement IMO.

[orbea]

I never said anything about updating cores automatically? I'm not sure you really understood the suggestion. Additionally I have never seen a savastate fail to work when a core has been updated.

[LaserMoai]

I meant to say along with the OS updates.

[orbea]

In the case of Slackware this would not happen because the build scripts are only run when the user wants them to. Relying entirely on the online updater and buildbot for downstream distributions is not a good solution, but that does not mean its good to break that functionality either. Also the suggestion you linked could only compliment this one. :)

[kivutar]

I faced the same issue in Lakka and ended up using an OS side solution: overlayfs.

Union mounting is a common use case and we should avoid implementing it at the application level to avoid code duplication.

[t-paul]

Using overlayfs is easy when configuring a special distribution like lakka. In the general case it's not always easy or possible to use things that require root access.

While probably not very important, it would be a useful solution for general distributions to support both system (usually read-only for the user) and user folders. The first would be managed by installed packages and provide system wide access, the latter by the user downloading or manually compiling. In most cases it also would make sense to probe the user dir first to allow overwriting the system installed file.

[RobLoach]

PhysicsFS allows "mounting" multiple directories, and then "lazy loading" from different locations. Not sure if that's something that RetroArch would want to add in. It would solve some of these use cases though.

[orbea]

Convincing Pat to add overlayfs to Slackware just for RetroArch which is not in the official repo is not going to happen. I would not be surprised if other general distributions would not do this either. This is something that should be addressed in RetroArch itself rather than with a system specific hack.

I am not a developer so I may be overlooking something, but its pretty common with other programs to allow multiple paths for such as configuration files. Even RetroArch allows this by reading from both ~/.config/retroarch/ and /etc/retroarch.cfg. Would this be an entirely different concept?

[soredake]

Any progress on this?

[Cooky-12]

I prefer to download AppImage package from buildbot.libretro.com and etract it to /opt as root. When run it as normal user, it can't find its stuffs. I found a simple workaround, just symlink everything to ~/.config/, so it could use local stuffs and could be updated.

cp -Rs /opt/RetroArch-Linux-x86_64/RetroArch-Linux-x86_64.AppImage.home/.config/retroarch ~/.config/

Hope this will help.