[SOLVED] Creating a second, separate instance of a package

cathedral_junky · 2020-12-30 19:27:58

Strangely specific request but ok so lets say I have a program installed through pacman, in this case retroarch. I want to create like a second completely separate copy of this program for certain games with certain settings and create a separate name for it to treat it like a different program, its ok if this second one doesn't get updated by pacman. How exactly do I do this? In windows it was really as simple as just copy and pasting the installation folder, but I'm not so sure in this case since it seems to pull from multiple directories. Like I could copy ~/.config/retroarch to another folder and name it like retroarch2 for example, but the application itself is not located here, and there is a retroarch shared library folder in /usr/bin, as well as a folder in /usr/lib64. How should I go about this ?

Last edited by cathedral_junky (2020-12-30 22:00:50)

V1del · 2020-12-30 19:42:14

That just sounds like a weird idea as the entire idea of retroarch is to be all of that, by it's nature it's completely modular and there's little stopping you from using the Arch package base and adding nightly core builds or what have you. Do you have a specific usecase in mind? FWIW "retroarch" is primarily the UI with very little relevance regarding game compat.

But if you really feel you need to do that then yes there's little stopping you. You could literally just make a copy of the retroarch binary, or if you want to be more fancy for some reason pick the base package source rip out all the to be shared parts and just drop a binary where you want .

However I feel there's an XY problem here and you might want to elaborate on what you actually want to do. If you want to e.g. just run it off of different configuration then write a script that you drop into /usr/local/bin/ or so and call it with different arguments

Last edited by V1del (2020-12-30 19:52:44)

Slithery · 2020-12-30 20:04:54

Why not just run it as a seperate user? That way it should have completely isolated configuration files.

cathedral_junky · 2020-12-30 20:26:39

My usecase really is just to mimic a sort of "soft-fork" or unofficial customized version of retroarch called shmuparch [http://electricunderground.io/shmuparch] for windows, in linux. All in all really it is just a preconfigured retroarch with certain per-game settings for specific arcade games. Really I COULD just have one big retroarch and set my configurations per-core and per-game or whatever, I am just used to (from windows) and prefer to have two separate builds: one minimal version specifically set up for arcade shoot em ups, and another for everything else. Sounds silly to anyone else I'm sure I just like to have almost completely different global defaults between arcade games of this type and everything else. Its more just about keeping settings and libraries completely separate than game compatibility. I guess my question really was how would I go about having essentially two different versions of retroarch, as Im not really sure what I would copy exactly, In windows pretty much everything was located in a single folder making it easy to have multiple versions. I tried copying and renaming the binary and then within retroarch pointing to new folders for each item in the .config (so pointing to a different cores folder, autoconfig folder, retroarch.cfg, etc.) but changes still seem to sync between them for some reason.

seth · 2020-12-30 20:38:43

man retroarch wrote:

--config PATH, -c PATH
Sets the configuration file path. retroarch will use this path to load the configu‐
ration file. Should this not be defined, retroarch will look in platform specific
paths to attempt finding the config file. /etc/retroarch.cfg (when installed), or
retroarch.cfg in the source tarball serves as a skeleton configuration file.
/etc/retroarch.cfg should serve as a skeleton config only.
Unix-like systems will look in $XDG_CONFIG_HOME/retroarch/retroarch.cfg first. If
$XDG_CONFIG_HOME is not defined, it is assumed to be $HOME/.config as per specifi‐
cation. Then it will try $HOME/.retroarch.cfg. If both paths fail, RetroArch will
try to create a new, default config file in $XDG_CON‐
FIG_HOME/retroarch/retroarch.cfg (or the $HOME/.config default for $XDG_CON‐
FIG_HOME). If all fails, default settings will be assumed. If RetroArch creates a
new default config file, it will attempt to load the skeleton config file
/etc/retroarch.cfg and use that as a basis. This allows distributions to set up
default paths for libretro cores, and similar things. A configuration file does
not need to define every possible option, only those which should be overridden.
If config_save_on_exit = true is set in the config file, RetroArch will overwrite
the config file on exit. Settings can be changed from within the menu. If
RetroArch overwrites a config file, formatting, comments, etc will be lost. If
RetroArch creates a default config file, it will have config_save_on_exit set auto‐
matically.
Windows will look in retroarch.cfg in same folder where retroarch.exe resides. A
default config file will also be created in the same manner as Unix.
--appendconfig PATH
Appends a different set of config files to the config file loaded in -c (or de‐
fault). Multiple config files are delimited by ','. Every config file will be ap‐
pended in order where the key-value pairs of the next config file takes priority
over the old ones.
--subsystem SUBSYSTEM
Use a subsystem of the loaded libretro core. Multiple content files are loaded as
multiple arguments. If content is skipped, use a blank ("") command line argument.
Content must be loaded in an order which depends on the particular subsystem used.
See verbose log output to learn how a particular subsystem wants content to be
loaded.

jaywk · 2020-12-30 21:07:28

Perhaps using an appimage might be a solution.

In order to use different config files -if necessary- you could make use of the --config option, i.e.

retroarch --config ~/path/to/other/configfile/other_retroarch.cfg

cathedral_junky · 2020-12-30 21:19:34

Using --config works great actually thanks a lot for the suggestions, was confusing because of the way retroarch autosaves to a default location on exit, setting it so the default one save on exit and the alternate cfg does fix everything.

Last edited by cathedral_junky (2020-12-30 22:01:23)

Trilby · 2020-12-30 21:37:58

Is that a typo? What's not fixed? You can specify the location for the autosaves.

V1del · 2020-12-30 21:40:05

Yes that's what I was rather trying to get at. If this is [SOLVED] please mark it as such by editing the thread title and appending that, maybe adjusting the title in general to rather reflect what you ended up doing.

cathedral_junky · 2020-12-30 22:00:35

Trilby wrote:

Is that a typo? What's not fixed? You can specify the location for the autosaves.

was a typo yes, sorry

Arch Linux

#1 2020-12-30 19:27:58

[SOLVED] Creating a second, separate instance of a package

#2 2020-12-30 19:42:14

Re: [SOLVED] Creating a second, separate instance of a package

#3 2020-12-30 20:04:54

Re: [SOLVED] Creating a second, separate instance of a package

#4 2020-12-30 20:26:39

Re: [SOLVED] Creating a second, separate instance of a package

#5 2020-12-30 20:38:43

Re: [SOLVED] Creating a second, separate instance of a package

#6 2020-12-30 21:07:28

Re: [SOLVED] Creating a second, separate instance of a package

#7 2020-12-30 21:19:34

Re: [SOLVED] Creating a second, separate instance of a package

#8 2020-12-30 21:37:58

Re: [SOLVED] Creating a second, separate instance of a package

#9 2020-12-30 21:40:05

Re: [SOLVED] Creating a second, separate instance of a package

#10 2020-12-30 22:00:35

Re: [SOLVED] Creating a second, separate instance of a package

Board footer