-
-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issues when provides
is removed
#2740
Fix issues when provides
is removed
#2740
Conversation
Let's do a 1.26.2 release without this. It's kind of a big change and it would be nice to have a bug-fix release with no new bugs in it. |
In accordance with new release process, it'll be 1.26.2 that we release, making 1.26.1 the dev release that allows people to use the built-in upgrader. Sorry I've been a bit absent - messing about with switching to a different Distro - I'm giving Manjaro a try. |
c8852b6
to
18cf66e
Compare
Just tested if this would fix KSP-CKAN/NetKAN#7210 (comment),
"Normal" output would be:
GUI doesn't crash, behaves like master. |
@DasSkelett are you still getting that error? |
Well, this specific case is solved, and I can't recreate the crash with custom relationships for now. |
Problem
If a module
provides
another module and then later we remove that property, installing a mod that depends on the provided mod can prompt you to make the same decision multiple times and raise exceptions like this:Cause
See KSP-CKAN/NetKAN#7149 for full details of the situation that brought this to our attention.
After the user chooses a
CkanModule
, CmdLine discards the fullCkanModule
in favor of just the identifier here:CKAN/Cmdline/Action/Install.cs
Lines 203 to 204 in 7b9da8c
When we next try to resolve that install command, it uses the latest version of the module rather than the one the user selected.
GUI is slightly more complicated. When you check the box for a module that depends on a virtual module, the prompt to choose a module appears immediately, and the checkbox of the user's choice is checked in the mod list.
CKAN/GUI/MainDialogs.cs
Lines 86 to 87 in 7b9da8c
This approach can't work in the general case, because there is no checkbox for installing an older version of a module (related to why I haven't taken a stab at #2715). Instead, this can only ever install the latest version, even if it's not what the relationship resolver gave us to select.
(ConsoleUI already handles this mostly correctly, except that the user is allowed to upgrade into an inconsistent state, which I'm not attempting to address here.)
Changes
Now CmdLine tracks its list of mods to install as a list of
CkanModule
s, and if the user needs to choose a providing mod, the exactCkanModule
they chose is added to that list and we try again.Now GUI won't prompt you to choose providing mods until you apply the changes, and it will install the version of the modules that the relationship resolver gives it.
Fixes #2738.
Two tests are deleted:
ComputeChangeSetFromModList_WithConflictingMods_ThrowsInconsistentKraken
wasn't working as intended, see MainModList test is not working correctly #2741. It was trying to test that conflicts between installed and installing mods are caught, which is not broken in these changes:TooManyProvidesCallsHandlers
was trying to confirm that the provides-resolution prompt would appear when you click a mod with a virtual dependency, but that's just not how it works anymore. Now we handle them at install time.Fixes #2741.