Skip to content
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

Closed
thomasfinstad opened this issue Dec 21, 2024 · 6 comments · Fixed by #130
Closed

Removal of no longer managed entries fail if already manually removed. #126

thomasfinstad opened this issue Dec 21, 2024 · 6 comments · Fixed by #130
Assignees
Labels
bug Something isn't working
Milestone

Comments

@thomasfinstad
Copy link

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] (

${pkgs.flatpak}/bin/flatpak uninstall --${installation} -y $APP_ID
) the module assumes that the saved state is perfect, and will fail if the user have manually uninstalled the package beforehand. A simple check beforehand to make sure it is installed, something like ${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.

if ${pkgs.flatpak}/bin/flatpak --${installation} remotes --columns=name | grep -q "^$REMOTE_NAME$"; then
${pkgs.flatpak}/bin/flatpak remote-delete ${if uninstallUnmanaged then " --force " else " " } --${installation} $REMOTE_NAME
else
echo "Remote '$REMOTE_NAME' not found in flatpak remotes"
fi

PS: not sure if anyone cares, but this is currently my setup to "save" the live flatpaks to nix:

flatpak.nix
{
  home.packages = with pkgs; [
    flatpak

    (pkgs.writeShellApplication {
      name = "zzz-save-flatpak2nix";
      runtimeInputs = with pkgs; [
        flatpak
        gnused
        coreutils
        nixfmt
      ];

      derivationArgs = {
        nativeBuildInputs = [ pkgs.installShellFiles ];
      };
      excludeShellChecks = [ "SC2145" ];
      text = builtins.readFile ./save-flatpak2nix.sh;
    })
  ];

...

  # Use the shell script zzz-save-flatpak2nix to update desired remotes and packages from live system.
  services.flatpak = import ./flatpak2nix.nix // {
    enable = true;
...
  };
...
save-flatpak2nix.sh
#!/usr/bin/env bash

# Start
export LC_ALL=C
OUTPUT ="# Generated by $0\n"
OUTPUT ="{\n"

###
# Remotes
OUTPUT ="remotes = [\n"

OUTPUT ="$(flatpak remotes --columns=name,url | sort | sed -E 's/(.*)\t(.*)/{\nname="\1";\nlocation="\2";\n}\n/')"

OUTPUT ="];\n"

###
# Packages
OUTPUT ="packages = [\n"
readarray -t apps < <(flatpak list --app --columns=origin,ref)
readarray -t runtimes < <(flatpak list --runtime --columns=origin,ref)

OUTPUT ="\n###\n# Apps\n"
app_output=""
for app in "${apps[@]}"; do
  readarray -t -d $'\t' fpkg < <(echo -n -e "$app")

  if [ "${fpkg[0]}" == "flathub" ]; then
  	app_output ="\"${fpkg[1]}\"\n"
  else
  	app_output ="{origin=\"${fpkg[0]}\";appId=\"${fpkg[1]}\";}\n"
  fi
done
OUTPUT ="$(echo -e "$app_output" | sort -r)\n"

OUTPUT ="\n###\n# Runtimes that directly extends an app\n"
runtime_output=""
for runtime in "${runtimes[@]}"; do
  readarray -t -d $'\t' fpkg < <(echo -n -e "$runtime")
  extends="$(flatpak info -m "${fpkg[1]}" | sed -n -E -e '/ExtensionOf/,/^$/s/ref=((app|runtime)\/)?(.*)/\3/p')"

  if [ -n "$extends" ] && grep "$extends" <<<"${apps[*]}" >/dev/null; then
  	if [ "${fpkg[0]}" == "flathub" ]; then
  		runtime_output ="\"${fpkg[1]}\"\n"
  	else
  		runtime_output ="{origin=\"${fpkg[0]}\";appId=\"${fpkg[1]}\";}\n"
  	fi
  	#else
  	# if [ "${fpkg[0]}" == "flathub" ]; then
  	# 	runtime_output ="#\"${fpkg[1]}\"\n"
  	# else
  	# 	runtime_output ="#{origin=\"${fpkg[0]}\";appId=\"${fpkg[1]}\";}\n"
  	# fi
  fi
done
OUTPUT ="$(echo -e "$runtime_output" | sort -r)\n"
OUTPUT ="];\n"

# Fin
OUTPUT ="}"
echo -e "$OUTPUT" | tee "$HOME/code/nixos-config/home/$USER/apps/flatpak2nix.nix"
sync
nixfmt "$HOME/code/nixos-config/home/$USER/apps/flatpak2nix.nix"
example snippet of flatpak2nix.nix
{
  remotes = [
    {
      name = "Slicer";
      location = "https://rafaelpalomar.github.io/org.slicer.Slicer-flatpak-repository";
    }
    {
      name = "flathub";
      location = "https://dl.flathub.org/repo/";
    }
  ];
  packages = [

    ###
    # Apps
    {
      origin = "Slicer";
      appId = "org.slicer.Slicer/x86_64/master";
    }
    "xyz.tytanium.DoorKnocker/x86_64/stable"
    "rocks.koreader.KOReader/x86_64/stable"
    "rest.insomnia.Insomnia/x86_64/stable"
...

    ###
    # Runtimes that directly extends an app
...
    "io.github.ungoogled_software.ungoogled_chromium.Codecs/x86_64/stable"
    "com.jeffser.Alpaca.Plugins.AMD/x86_64/stable"
  ];
}
@gmodena
Copy link
Owner

gmodena commented Dec 28, 2024

Hey @thomasfinstad

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.

Ah cool. This is a workflow I did not really consider. Thanks for sharing your setup!

the module assumes that the saved state is perfect, and will fail if the user have manually uninstalled the package beforehand.

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:

A simple check beforehand to make sure it is installed, something like ${pkgs.flatpak}/bin/flatpak info "$APP_ID" && ${pkgs.flatpak}/bin/flatpak uninstall --${installation} -y $APP_ID would fix this.

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 gmodena self-assigned this Dec 28, 2024
@gmodena gmodena added this to the 0.6.0 milestone Dec 28, 2024
@thomasfinstad
Copy link
Author

@gmodena Thanks for the feedback, glad the suggested change is acceptable.

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.

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.

  1. add a flatpak to nix-flatpak list
  2. rebuild nix
  3. manually flatpak uninstall the package
  4. remove the flatpak from the nix-flatpak list
  5. rebuild nix ERROR

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.

@gmodena
Copy link
Owner

gmodena commented Dec 29, 2024

@thomasfinstad thanks for clarifying.

Just to confirm: we are on the same page, and I can repro your workflow.

@thomasfinstad
Copy link
Author

Were you able to reproduce it on your own system?

@gmodena
Copy link
Owner

gmodena commented Dec 30, 2024

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:

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.

Here I was wrong. The issue you reported is triggered when uninstallUnmanaged=false, as the state management logic does not reconcile the state in this scenario.

This is definitely a bug. Thank you very much for flagging it!

@gmodena gmodena added the bug Something isn't working label Dec 30, 2024
@gmodena
Copy link
Owner

gmodena commented Jan 3, 2025

@thomasfinstad I merged #130 after some days of daily driving. Feel free to re-open if you still encounter issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants