Updater Script Fetching Latest MiSTer.ini

[jayp76]

@Locutus73

Hello,

i see often people online having no MiSTer.ini or an outdated MiSTer.ini with missing options.
My idea was to have a user.ini, which retains the user settings and supersedes the MiSTer.ini options, while the updater always fetches the latest one.
But this has to be integrated into the MiSTer OS. This is not my request. Alternatively the updater fetches the latest file to the root, with a timestamp,
so users can see there is a new one and can adapt their settings.

Best regards
Jay

[RealLarry]

Good suggestion, would be happy to get such a solution in either way. I'm fetching and diff'ing MiSTer.ini every few weeks for now.

[Locutus73]

You can easily implement that with something like

Code: Select all

ADDITIONAL_REPOSITORIES+=( "https://github.com/MiSTer-devel/Main_MiSTer|ini|$BASE_PATH/ini_examples" )

you will have an always updated MiSTer.ini in /media/fat/ini_examples.
Actually the ini_settings.sh downloads (but it doesn't update it) the MiSTer.ini file when it's not on the SD (and when there's no MiSTer_example.ini on the SD)... the script should cover all settings, I think currently one or two settings are missing. Please tell me/notify me when something is missing.

Thank you in advance.
Regards.

Locutus73

[jayp76]

Thank you for your example. In this case the user has to do it itself. Shouldn't it be mandatory for the users that are not that savvy with the scripts? Just my two cents. If it is documented in the wiki or github i can live with it.

[Locutus73]

Thank you for your example. In this case the user has to do it itself. Shouldn't it be mandatory for the users that are not that savvy with the scripts? Just my two cents. If it is documented in the wiki or github i can live with it.

I'm sorry... I, ehm, don't understand what you're suggesting.

Regards.

Locutus73

[keith.f.kelly]

The fundamental problem is MiSTer.ini files that are missing some settings entirely (due to support for new ones having been added unbeknownst to the user) and/or that are trying to use settings that have been deprecated (due to support for them being removed in newer MiSTer releases)... but we also don’t want to overwrite any user settings or comments that they modified on purpose.

Possible solution: If the updater script could just compare the set of options present in the latest available example with the set of options present in the user’s MiSTer.ini and just notify the user (in the updater script summary) if options have been added or removed, that would address all concerns, right?

[jayp76]

@Locutus73
Just looking for a solution that is for everyone feasable. Your suggestion is good.
@Bits'n'Stuff
I also like your approach.

[RealLarry]

We could modify and use Gentoo's etc-update https://wiki.gentoo.org/wiki/Handbook:X ... etc-update
That's what I'm using daily at my ArchLinux and OpenSuSE systems (and years before when I was using Gentoo).

[Locutus73]

Honestly I think that merging the online MiSTer.ini with the local one is an overkill (managing the diff between current and new settings, the comments which may be on top, on the right or on the bottom of a setting, multiple options with the same comments, etc.) and editing the local ini is too aggressive towards the end user. If we want something targeted to non technical users, then there's the ini_settings.sh script, with a text user interface (you can see there all unset parameters); I will be glad if anyone can help me alerting me whenever there's a new option. Tech heads can add a line to the ADDITIONAL_REPOSITORIES updater parameter, compare files and manually edit their MiSTer.ini.

Regards.

Locutus73

[HackerJack42]

What about the tried-and-true method of providing a clean mister.ini-dist with updates? This would require a change to the mister binary for first boot or factory reset cases. If mister.ini is not present on the card, copy mister.ini-dist to mister.ini.

It would be nice if the ini_settings.sh script got fancy and automated a diff and update, but I'm not going to hold my breath on that one. In my eyes, having a separate fresh ini file with the latest recommended settings readily available on the card provides more value than trying to bodge together some automated diff/update that will inevitably bork someone's heavily customized ini.

No offense intended toward the people writing the scripts. I just know that there is no way to truly "idiot proof" something.

[Sigismond0]

The ini_settings.sh doesn't need to do any diffchecks and merge new ini files or anything. It shows you all the valid options, regardless of what your old ini has set as long as the script is kept up to date. So if you have an old ini without the expand_browse option for example, just launch the ini_settings script and you can set that value and add it to your ini.

Locutus, am I interpreting that correctly?

[Locutus73]

The ini_settings.sh doesn't need to do any diffchecks and merge new ini files or anything. It shows you all the valid options, regardless of what your old ini has set as long as the script is kept up to date. So if you have an old ini without the expand_browse option for example, just launch the ini_settings script and you can set that value and add it to your ini.

Locutus, am I interpreting that correctly?

Exactly... and you will see something like “Not set or commented” in the value of expand_browse option, that means it’s probably a new setting (or something commented since the beginning).

Problem is: I might be unaware a new setting has been added to MiSTer.ini, so ini_settings.sh may not contain all new options (I recently update it with all options). Alerting me whenever there something new may help.

Thank you in advance.
Regards.

Locutus73

[Locutus73]

What about the tried-and-true method of providing a clean mister.ini-dist with updates? This would require a change to the mister binary for first boot or factory reset cases. If mister.ini is not present on the card, copy mister.ini-dist to mister.ini.

It would be nice if the ini_settings.sh script got fancy and automated a diff and update, but I'm not going to hold my breath on that one. In my eyes, having a separate fresh ini file with the latest recommended settings readily available on the card provides more value than trying to bodge together some automated diff/update that will inevitably bork someone's heavily customized ini.

No offense intended toward the people writing the scripts. I just know that there is no way to truly "idiot proof" something.

I totally agree with you, and editing autonomously adding stuff to the ini is way too aggressive IMHO.
Try adding

Code: Select all

ADDITIONAL_REPOSITORIES+=( "https://github.com/MiSTer-devel/Main_MiSTer|ini|$BASE_PATH/ini_examples" )

to your update.ini, you will have an always updated MiSTer.ini in /media/fat/ini_examples.
Whenever you launch ini_settings.sh if there’s no MiSTer.ini, but MiSTer_example.ini exists, it will copied to MiSTer.ini, otherwise it will be downloaded from GitHub.

Regards.

Locutus73

[RealLarry]

Try adding

Code: Select all

ADDITIONAL_REPOSITORIES+=( "https://github.com/MiSTer-devel/Main_MiSTer|ini|$BASE_PATH/ini_examples" )

to your update.ini, you will have an always updated MiSTer.ini in /media/fat/ini_examples.
Whenever you launch ini_settings.sh if there’s no MiSTer.ini, but MiSTer_example.ini exists, it will copied to MiSTer.ini, otherwise it will be downloaded from GitHub.

Checked and works. That's something I can live with very well. Thank you!