-
Notifications
You must be signed in to change notification settings - Fork 15
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
Removal of no longer managed entries fail if already manually removed. #126
Comments
Hey @thomasfinstad
Ah cool. This is a workflow I did not really consider. Thanks for sharing your setup!
This is more of a design decision. If you intend to "tamper" with the state, nix-flatpak assumes you’ll run it with uninstallUnmanaged=false. Initially, I wanted the module to flag any inconsistencies with expected behavior. However:
1. As you pointed out, this behavior is already implemented in other parts of the codebase. I'm okay with relaxing the strictness and having the module log or warn about state mismatches instead of hard failing during removal. |
@gmodena Thanks for the feedback, glad the suggested change is acceptable.
I think I might have explained how the problem occur a bit poorly, so while the problem sounds like it will be fixed, I just wanna try to clarify exactly what the problem is so remove any chance of a X/Y problem type situation. I have uninstallUnmanaged=false in my config already.
On step 5 nix-flatpak finds the flatpak in the old state and so tries to remove it, but it is already gone. Perhaps I mean the json file when I say state and you mean the system live state when you say state and that is the miscommunication, but either way I hope its a bit more understandable exactly what my use-case / workflow is and how I bump into the mentioned issue. |
@thomasfinstad thanks for clarifying. Just to confirm: we are on the same page, and I can repro your workflow. |
Were you able to reproduce it on your own system? |
Yep. There's a fix the linked PR (warn-on-uninstall-missing branch). From a previous comment:
Here I was wrong. The issue you reported is triggered when This is definitely a bug. Thank you very much for flagging it! |
@thomasfinstad I merged #130 after some days of daily driving. Feel free to re-open if you still encounter issues. |
This is kind of an issue for those of us that like me prefer to configure my flatpaks interactively, then dump it into a nix file so my desired state is declarative.
During the removal of [packages] (
nix-flatpak/modules/installer.nix
Line 111 in 8bdc254
${pkgs.flatpak}/bin/flatpak info "$APP_ID" && ${pkgs.flatpak}/bin/flatpak uninstall --${installation} -y $APP_ID
would fix this.It seems the remotes already have this style of check implemented, just a tiny bit differently than what I did above.
nix-flatpak/modules/remotes.nix
Lines 31 to 35 in 8bdc254
PS: not sure if anyone cares, but this is currently my setup to "save" the live flatpaks to nix:
flatpak.nix
save-flatpak2nix.sh
example snippet of flatpak2nix.nix
The text was updated successfully, but these errors were encountered: