-
Notifications
You must be signed in to change notification settings - Fork 110
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
Errors when refreshing repositories can lead to unintended vendor changes #446
Comments
This limitation impacted us again: https://progress.opensuse.org/issues/150845 Here many important packages have been uninstalled completely and if would have helped if zypper had aborted after refreshing didn't work. |
Martchus
added a commit
to Martchus/openQA
that referenced
this issue
Nov 14, 2023
* Same as eef44e1 but for openqa-auto-update * Workaround openSUSE/zypper#446 * See https://progress.opensuse.org/issues/150845
Martchus
added a commit
to Martchus/openQA
that referenced
this issue
Nov 14, 2023
* Same as eef44e1 but for openqa-auto-update * Workaround openSUSE/zypper#446 * See https://progress.opensuse.org/issues/150845
Maybe we can change this legacy behavior for 15.6/TW. |
So there's already a switch to change this behavior? |
No, we need to create one to be strict/relaxed. |
openqa-git-sync
pushed a commit
to os-autoinst/salt-states-openqa
that referenced
this issue
Mar 26, 2024
openqa-git-sync
pushed a commit
to os-autoinst/salt-states-openqa
that referenced
this issue
Mar 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When calling
zypper dup
repositories are refreshed before the actual update (depending on the configuration of course). If repositories can not be refreshed they are ignored and the update is continued anyways. That behavior is rather dangerous as it can lead to unintended vendor changes.This ticket gives and example: https://progress.opensuse.org/issues/112595#Observation
Here we generally want vendor changes to happen (in case we add/remove packages in our custom repo) so we generally allow vendor changes and run and everything happens unattended for the sake of automation. That we might end up with a completely unintended vendor changes because one configured repository is not considered at all is quite dangerous. It woulds be much safer if zypper would abort when refreshing doesn't work.
One can easily reproduce this by e.g. breaking one repository URL (of a repository where auto-update is enabled) and calling
zypper dup
. E.g. herezypper
just skipped the repo and continued instead of aborting due to the error leading zypper to propose an unwanted vendor change:The text was updated successfully, but these errors were encountered: