The implementation looks rather simple. When upgrading a system using the installation media (network-based as well) the currently enabled system repositories are offered to be reused during the upgrade itself possibly with modifying the URL (e.g., 11.0 to 11.1) using the [Change...] button.
It's been a while since the basic feature implementation. Several additional (and often hidden) features were also added in openSUSE 11.0 and 11.1. Now it's time to completely rewrite this part of installation to better meet the user expectations.
This is the newly proposed functionality:
- Initially, all repositories are proposed to be re-added to the new system but in a disabled state.
- User can change the new status to enabled or deleted state.
- User can change the repository URL, Name and Priority.
- User can be offered an automatic rewriting of the URL if possible, e.g., /10.3/ to /11.1/ if detected (default behavior).
- All other repository settings are kept (alias, refresh, ...)
- If any of the repositories is remote, the network setup is be checked for existence and user is allowed to set it up if not yet configured.
- Simple to understand ...
3 comments:
It might be also possible to rewrite this step as part of the installation/upgrade proposal.
That would cover the proposed defaults feature and it could possibly make it easier to understand, change and tune.
User can change the new status to enabled or deleted state.
Does this mean, in other words, that user can delete the repository? Why not to offer 'delete this repository' functionality right away? By switching the status (does deleted status exist at all?) in this way it is sort of cumbersome.
In other words, this dialog is visible during the upgrade (upgrade proposal). No changes should be done before user finally accepts the proposal by clicking on the [Upgrade Now] button.
Which means that user should be able to change the status several times between (repository will be) deleted, enabled, or disabled.
Additionally, if a repository is in the enabled state, the upgrade proposal should initialize it and recall software proposal as the list of currently enabled repositories can affect the proposal itself (and remove the initialized repository from memory when user selects one of the other states). Yes, it's a bit complicated.
Post a Comment