midwan
commented
2 months ago OK, let's fix this, as it would be helpful in integrating Amiberry in various systems easier. I'm thinking of the following logic, during the startup initialization of paths stage:
- If
AMIBERRY_DATA_DIRis set, look for thedatadirectory there - If the variable is not set, look for
datain/usr/share/amiberry/data- if found, that path will be set as the "data_path" - If not found, look for
datain the current directory. This is essentially the fallback we have today, allowing for "portable" installations (all under one directory).
The above defaults to the expected directory in a normal distro installation (is there a variable for that, or should the path be hardcoded I wonder?), but still allows overriding it with the ENV variable if needed.
Regarding the rest of the directories, I'm thinking about the best place to look for (the fallback on the current dir will remain as the last option). Should it be under $HOMEDIR/.amiberry/ ? I need to see what's the standard practice for these, to determine that.
Eventually I'd like to create a package (e.g. .deb or similar) which users can use to install or upgrade Amiberry. Ideally push it up to the Debian repos as well, though that requires some work, from what I saw in their docs. So these things with the directory handling should be done first, in any case.
linux / PLATFORM=x86-64 /amiberry 5.6.1 (github clone)
Using strace, I see amiberry references $PWD when launched to find it's support files
Premise;
The support 'data' files for amiberry itself, might be typically found somewhere like '/usr/share/Amiberry/data'
The other support directories/files (conf/, controllers/, inputrecordings/, kickstarts/, nvram/, savestates/, screenshots/ etc) are pretty much user configurations/files, and not 'system wide' as such like above data dir. These dirs/files might typically be found in /home/username/Amiberry/
If one sets the env variable EXTERNAL_FILES_DIR=/usr/share/Amiberry , the amiberry binary treats that as the source dir for all required directories/files (including those that would typically reside in user's $HOMEDIR)
Possibly the variable namespace 'EXTERNAL_FILES_DIR' seems vulnerable to me, and something like 'AMIBERRY_DATA_DIR' makes more sense, and the amiberry binary should look there for 'data', and in user's $HOMEDIR for configuration files and everything else....ie; $PWD/Amiberry (note: $HOMEDIR/Amiberry is preferable to having all the amiberry directories sprayed into user's ~/ )
My current workaround is to set EXTERNAL_FILES_DIR=/home/username/Amiberry/ and have all the amiberry resources under that directory (including a copy of the 'data' directory & files from the build tree).
I would only consider this a packaging issue when it comes to a binary package release =)