Safe update mechanisms (#93) · Issues · portmod / Portmod

Safe update mechanisms

There are many mods that can safely be updated without causing any save game issues, and I believe there are some that will also cause issues (frankly I haven't been playing OpenMW recently and don't know of any specific examples of updates that break a savegame).

I propose three new flags to allow the restriction of certain updates.

-F, --safe. Only update asset mods. More specifically, skip updates except where the old mod does not contain any plugin files (update could add a plugin, but this should be safe as far as I know).
-m, --minor. Skip mods with major revision changes. E.g. A mod updating from v4.0.0 to v4.0.1 is okay, or even v4.1.0, but v5.0.0 would be skipped, as it likely contains breaking changes. This will likely not be used by itself.
-M, --safe-or-minor. Update mods that are either safe (would be pulled in by -F), or a minor update (would be pulled in by -m). Note that -mF would mean safe and minor, i.e. only perform minor updates to safe mods. -M cannot be used alongside either of -m or -F.

In general, you could then use

omwmerge -uDN @world (existing option) to update mods in an unsafe manner, such as when you're still setting up a mod config.
omwmerge -uFDN @world as a conservative option that will almost never break things (at worst, there might be missing assets).
omwmerge -uMDN @world as a less conservative option that will still avoid major changes.
omwmerge -umFDN @world could also be an ultra-conservative update method to try to avoid significant changes to how assets look.

Also note that you could run an unsafe update after a safe update (and cancel it) to see what potentially unsafe mods can be updated, checking their documentation manually to see if there are any breaking changes (--pretend might be a useful option to add at some point, though we do require confirmation by default).

Implementation details for Safe/Unsafe mods

This should be set via profile, noting that the idea of a safe mod may differ between OpenMW and Tes3MP, as Tes3MP scripts may not be safe (frankly I'm just guessing here, feel free to correct me).

We should introduce an UNSAFE_FILES variable in the profile that should compare file categories (e.g. PLUGINS to those present in the mod, and declare the change unsafe if the old version contains a file in those categories and the REQUIRED_USE for that file has been satisfied.

We should also introduce the PROPERTIES flags unsafe-upgrade and safe-upgrade, to allow whitelisting and blacklisting of certain mods.

Transaction Prompt Changes

There is another option that might be more verbose, in that we could automatically break up the transaction list into these categories (yaourt, sadly unmaintained, does this for package, and version updates) and give the user some way of choosing which mods they want to upgrade. This would basically be a different interface for the same system, and we could even implement both, as the flags would be useful if bypassing the prompt and are simpler to use.

E.g. When displaying the transaction list, we could divide it into the following categories (there are other categories that I'm including than those mentioned above, as they would also be useful):

to be removed (currently we don't remove mods during updates, but it will sometimes be necessary)
changed revision
minor version changed (given that there could be many minor versions, this just matches anything non-major. It would be too complicated to have separate categories for each type of minor revision)
major version changed

Each type of version (save for to be removed) gets divided into the following:

Probably Safe (no plugin files in the old version)
Possibly Unsafe (old version has plugin files)

Finally, the user prompt, rather than Y/N, becomes Y/N/M, where M then prompts the user to manually select packages from the list. (While we're expanding on the post-transaction-list prompt, we could also add a way to view more details about the changes, e.g. view differences, open changelogs if available, etc., but that should probably be a separate issue).

Issues

Manually selecting mods from the list may leave dependencies unsatisfied. An option here is to simply complain to the user and loop the prompt until the selected mods can install properly, as well as indicate which mods are being installed as dependencies of other mods in the list.
This would break how we currently sort transactions (i.e. this list gives no indication of the order in which they will be installed, and makes portage's --tree option, which would be nice to implement eventually, unusable). However we could produce two transaction lists, one that is divided into categories as above, and one that shows the sorted list of what the user has chosen to install.
A solution that works for both of the above would be to have the first transaction list (see issue 2) not contain dependencies. The issue here is that you won't be warned about major updates and unsafe dependencies, and we probably don't want a prompt for each layer in the dependency tree. Displaying the first transaction list in tree form is probably the best option, with indications if an update to a dependency is necessary due to a version requirement.

I propose three new flags to allow the restriction of certain updates.

1. `-F`, `--safe`. Only update asset mods. More specifically, skip updates except where the old mod does not contain any plugin files (update could add a plugin, but this should be safe as far as I know).
2. `-m`, `--minor`. Skip mods with major revision changes. E.g. A mod updating from v4.0.0 to v4.0.1 is okay, or even v4.1.0, but v5.0.0 would be skipped, as it likely contains breaking changes. This will likely not be used by itself.
3. `-M`, `--safe-or-minor`. Update mods that are either safe (would be pulled in by `-F`), or a minor update (would be pulled in by `-m`). Note that `-mF` would mean safe and minor, i.e. only perform minor updates to safe mods. `-M` cannot be used alongside either of `-m` or `-F`.

In general, you could then use 
- `omwmerge -uDN @world` (existing option) to update mods in an unsafe manner, such as when you're still setting up a mod config.
- `omwmerge -uFDN @world` as a conservative option that will almost never break things (at worst, there might be missing assets).
- `omwmerge -uMDN @world` as a less conservative option that will still avoid major changes. 
- `omwmerge -umFDN @world` could also be an ultra-conservative update method to try to avoid significant changes to how assets look.

Also note that you could run an unsafe update after a safe update (and cancel it) to see what potentially unsafe mods can be updated, checking their documentation manually to see if there are any breaking changes (`--pretend` might be a useful option to add at some point, though we do require confirmation by default).

### Implementation details for Safe/Unsafe mods
This should be set via profile, noting that the idea of a safe mod may differ between OpenMW and Tes3MP, as Tes3MP scripts may not be safe (frankly I'm just guessing here, feel free to correct me).

We should introduce an `UNSAFE_FILES` variable in the profile that should compare file categories (e.g. `PLUGINS` to those present in the mod, and declare the change unsafe if the old version contains a file in those categories and the REQUIRED_USE for that file has been satisfied.

We should also introduce the `PROPERTIES` flags `unsafe-upgrade` and `safe-upgrade`, to allow whitelisting and blacklisting of certain mods.

## Transaction Prompt Changes
There is another option that might be more verbose, in that we could automatically break up the transaction list into these categories ([yaourt](https://archlinux.fr/yaourt-en), sadly unmaintained, does this for package, and version updates) and give the user some way of choosing which mods they want to upgrade. This would basically be a different interface for the same system, and we could even implement both, as the flags would be useful if bypassing the prompt and are simpler to use.

E.g. When displaying the transaction list, we could divide it into the following categories (there are other categories that I'm including than those mentioned above, as they would also be useful):

- to be removed (currently we don't remove mods during updates, but it will sometimes be necessary)
- changed revision
- minor version changed (given that there could be many minor versions, this just matches anything non-major. It would be too complicated to have separate categories for each type of minor revision)
- major version changed

Each type of version (save for to be removed) gets divided into the following:
- Probably Safe (no plugin files in the old version)
- Possibly Unsafe (old version has plugin files)

### Issues
1. Manually selecting mods from the list may leave dependencies unsatisfied. An option here is to simply complain to the user and loop the prompt until the selected mods can install properly, as well as indicate which mods are being installed as dependencies of other mods in the list.
2. This would break how we currently sort transactions (i.e. this list gives no indication of the order in which they will be installed, and makes portage's `--tree` option, which would be nice to implement eventually, unusable). However we could produce two transaction lists, one that is divided into categories as above, and one that shows the sorted list of what the user has chosen to install.
3. A solution that works for both of the above would be to have the first transaction list (see issue 2) not contain dependencies. The issue here is that you won't be warned about major updates and unsafe dependencies, and we probably don't want a prompt for each layer in the dependency tree. Displaying the first transaction list in tree form is probably the best option, with indications if an update to a dependency is necessary due to a version requirement.

Edited Oct 20, 2019 by Benjamin Winger