theypsilon
commented
2 years ago Very cool that you are already taking advantage of custom DBs. One thing I wanted to make clear first is that they are not officially supported yet. You can use it if you want, but I might change something one day and that could break your setup (not very likely though). I'll document it in the near future, and then I'll commit to a stable format and it will be officially supported.
I'll give you a quick solution before going into the suggestions. You could rename a copy of downloader.sh to for example download_my_cores.sh, and if you do so, it will try to read what you have at /media/fat/download_my_cores.ini . That could be a way to solve your problem, deactivating the main downloader in update_all and running this one separately.
About your suggestions, I'm a bit hesitant of adding envvar flags, but maybe we could have some other alternative, I'll have to think about how. Right now, the way I run the downloader for each category is not what it should be. It was a quick change to release a new version of update_all earlier, but in the future, the idea is that the downloader will be run just one time covering all the categories. When that comes, you won't have this problem anymore.
zakk4223
This may turn out to be more of a Mister downloader thing, but since it's firmly in the 'unofficial' category, I figured I wouldn't pollute the official repos with it...
Here's my quick use case: I have some private builds of the main MiSTer binary and possibly a few cores in the future. Since I'm lazy I'd like them to get updated when I run the update scripts. I have github workflows setup to auto-build them when appropriate, and I generated a downloader database for them. I added a database section to downloader.ini and it seems to work ok (although I think there are still situations where the wrong thing can get downloaded, but that's another issue..)
Unfortunately this is completely incompatible with update_all's jotego/llapi/unofficial downloaders. Those runs will basically just re-run the normal downloader since they rely on the DEFAULTDB environment variables which only get used if there aren't any databases defined in the ini file.
Would it perhaps be possible to add another envvar to the official downloader script that causes it to ONLY use the DBDEFAULT vars? Maybe by just disabling any processing of databases in the ini? Then have update_all just set that env for the 'extra' runs?
Alternately some way to have update_all run extra downloaders of custom databases, but that sounds like more work ;)
I can do the work in the downloader python to enable this, but I wanted to bring it up in case you're already working towards something like that.