With binaries, if we update a scriptmodule, we can rebuild or update the date on the binaries to force
an update. However, with the source installs, if the remote repository is not updated, an update won't
happen until it does. This could be an issue in a situation where we notice a bug in the module. In this
case we check if the module date is newer than the install date - and if so, we force an update.
Previously we eval's the return of getPackageInfo so the package variables could be created
locally to the function. However, due to the use of a subshell we couldn't cache anything in a variable
for use later.
The functions is now renamed to rp_loadPackageInfo and loads the package information into __mod_info[ID/FIELD]
eg. __mod_info[ID/pkg_origin] will contain the retropie.pkg origin field for the installed module
It also uses just grep to load the data rather than our existing ini functions for performance. As it's not
considered a user editable file, performance is key here, as we need this data when traversing the
RetroPie-Setup menus.
If a full load of a retropie.pkg is done, __mod_info[ID/pkg_info] is set to 1, as a cache flag so the data can be
reused without reloading on an additional call. rp_SetPackageInfo will clear this flag
Optional parameters for rp_loadPackageInfo can choose individual fields but if used the data won't be
cached, but it can be a lot faster - we use this to grab pkg_origin for the section menus in RetroPie-Setup.
These changes allow storing of source repo information in retropie.pkg as well as the ability
to check for a new version. To do this, repository information needs to be moved to the variable
md_module_repo in the format
md_module_repo="TYPE URL BRANCH COMMIT"
Currently types of file, git, or svn are suppported.
If using file the BRANCH and COMMIT are not used.
If using svn the BRANCH should be - and the COMMIT is the SVN revision.
This information is split up and provided to the module in the form of
md_repo_type
md_repo_url
md_repo_branch
md_repo_commit
Previously if set and if md_build contained a git repository, it would reset it, to undo any patches we
may have so they get reapplied after next git update. However, if there wasn't a .git folder in md_build it would
still remove the folder, rather than leave it behind. Adjusted the logic to fix this, but this code is very old
and was a quick "hack" so needs revisiting with upcoming packaging changes.
Doing an additional grep on every module to check if it duplicated an additional module_id, added
more overhead than was ideal. However we can just do the check on 3rd party repos, which brings performance
back to how it was pretty much, and will have a slight overhead if a user has a 3rd party repo added
On the Raspberry Pi console, bold text results in a lighter colour, rather than actually being bold.
One user (it may not be a common issue) reported on their terminal that they couldn't see installed
packages. This was due to our "bold white" for installed applications which ended up being bold grey on a grey
background - so they couldn't see what was installed without hovering over it.
We don't colour installed packages now - but add unavailable packages as red.
This can always be changed later also if needed of course.
although it works as it is currently due to the flexibility of the unix "date" command, we should
standardise dates so we don't end up with different formats in the configs depending on webserver output etc.
Curl headers outputs as CRLF rather than LF. Remove styled output from curl (as a precaution), and
strip CR's via tr before piping to grep, but also just use grep for processing via perl regexp (-P).
Do a grep to extract the rp_module_id before sourcing a file and check if it has already been used.
We don't want additional modules overriding existing, or accidental duplication.
Store the path of a module in __mod_info(ID/path)
Display any info/error messages when launching setup as otherwise they wouldn't be seen - they are
shown otherwise at the end of retropie_packages.sh.
Original module required game data from Debian. Debian has since removed this data to due licence issues.
Having tested adjusting the module to use manually installed game data, at least on the RPI4 it doesn't seem
to work correctly, with some screen corruption and input issues.
If someone wants to take a look at this again, it can be re-added
Used to separate 3rd party packages from RetroPie ones. Added some extra menu items in setup showing
above each type like a heading with
---- VENDOR - TYPE ----
Where:
* VENDOR is RetroPie or the name of the folder the 3rd party repo is installed in
* TYPE is the module/package type such as emulator, libretrocore, port etc
Some users have found the ordering of the menus confusing and this should help with that also.
3rd party packages always appear at the end of a section
3rd party repositories can be checked out to RetroPie-Setup/ext
Repositories should be structured so you have:
ext/REPOSITORY/scriptmodules
Modules are only read from the following subfolders of scriptmodules
* emulators
* libretrocores
* ports
* supplementary
* admin
The version was bumped to 4.7.5 just after the 3rd_party_repos PR was merged. However this had a major
bug due to the change in way modules were scanned causing the md_type to contain a full path. It was reverted
minutes after merging, but in case anyone accidentally updated to it, I am bumping again which may help
identify if a user did an update during this short window
