-
-
Notifications
You must be signed in to change notification settings - Fork 396
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
flatpak install will attempt to rebase a ref that's not yet installed #3754
Labels
Comments
This is not exactly the behavior I'm seeing with Flatpak 1.12.1 on Fedora 36 Rawhide. It still fails with that error message but it also installs the EOL version, its dependencies, the new version, and its dependencies:
|
I'm working on a patch for this. |
mwleeds
added a commit
that referenced
this issue
Oct 12, 2021
Currently if the user specifies a ref to install that has been renamed via the end-of-life-rebased mechanism, for example "flatpak install com.visualstudio.code.oss", Flatpak erroneously tries to install both the old and new versions of the app. This happens because the code handling end-of-life-rebase conditions is written assuming the rebased app is being updated rather than installed for the first time. Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in end_of_lifed_with_rebase(), we treat a failure of flatpak_transaction_add_uninstall() as fatal and return FALSE from the signal handler, which means that the install operation that triggered the signal will not be skipped (see the docs for FlatpakTransaction::end-of-lifed-with-rebase). So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and ignore it, so that the installation of the old version of the renamed app will be properly cancelled. Fixes #3754
alexlarsson
pushed a commit
that referenced
this issue
Nov 15, 2021
Currently if the user specifies a ref to install that has been renamed via the end-of-life-rebased mechanism, for example "flatpak install com.visualstudio.code.oss", Flatpak erroneously tries to install both the old and new versions of the app. This happens because the code handling end-of-life-rebase conditions is written assuming the rebased app is being updated rather than installed for the first time. Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in end_of_lifed_with_rebase(), we treat a failure of flatpak_transaction_add_uninstall() as fatal and return FALSE from the signal handler, which means that the install operation that triggered the signal will not be skipped (see the docs for FlatpakTransaction::end-of-lifed-with-rebase). So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and ignore it, so that the installation of the old version of the renamed app will be properly cancelled. Fixes #3754
mwleeds
added a commit
that referenced
this issue
Jan 4, 2022
Currently if the user specifies a ref to install that has been renamed via the end-of-life-rebased mechanism, for example "flatpak install com.visualstudio.code.oss", Flatpak erroneously tries to install both the old and new versions of the app. This happens because the code handling end-of-life-rebase conditions is written assuming the rebased app is being updated rather than installed for the first time. Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in end_of_lifed_with_rebase(), we treat a failure of flatpak_transaction_add_uninstall() as fatal and return FALSE from the signal handler, which means that the install operation that triggered the signal will not be skipped (see the docs for FlatpakTransaction::end-of-lifed-with-rebase). So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and ignore it, so that the installation of the old version of the renamed app will be properly cancelled. Fixes #3754 (cherry picked from commit 3aa9a7f)
mwleeds
added a commit
that referenced
this issue
Jan 4, 2022
Currently if the user specifies a ref to install that has been renamed via the end-of-life-rebased mechanism, for example "flatpak install com.visualstudio.code.oss", Flatpak erroneously tries to install both the old and new versions of the app. This happens because the code handling end-of-life-rebase conditions is written assuming the rebased app is being updated rather than installed for the first time. Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in end_of_lifed_with_rebase(), we treat a failure of flatpak_transaction_add_uninstall() as fatal and return FALSE from the signal handler, which means that the install operation that triggered the signal will not be skipped (see the docs for FlatpakTransaction::end-of-lifed-with-rebase). So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and ignore it, so that the installation of the old version of the renamed app will be properly cancelled. Fixes #3754 (cherry picked from commit 3aa9a7f)
alexlarsson
pushed a commit
that referenced
this issue
Jan 11, 2022
Currently if the user specifies a ref to install that has been renamed via the end-of-life-rebased mechanism, for example "flatpak install com.visualstudio.code.oss", Flatpak erroneously tries to install both the old and new versions of the app. This happens because the code handling end-of-life-rebase conditions is written assuming the rebased app is being updated rather than installed for the first time. Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in end_of_lifed_with_rebase(), we treat a failure of flatpak_transaction_add_uninstall() as fatal and return FALSE from the signal handler, which means that the install operation that triggered the signal will not be skipped (see the docs for FlatpakTransaction::end-of-lifed-with-rebase). So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and ignore it, so that the installation of the old version of the renamed app will be properly cancelled. Fixes #3754 (cherry picked from commit 3aa9a7f)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yup, this one is my bad. Example says it all:
If the original ref isn't even installed yet, this shouldn't bother attempting to delete the old one. However, the rebase operation should still take place, otherwise any leftover data from the previous app won't be migrated over (which I'd think would be desired, though it's arguable). Ideally it could tell eol-rebase the state, but that would be an ABI break so I'll have to figure out a better way to do that...
The text was updated successfully, but these errors were encountered: