k.nick@dellnew:~> sudo zypper dup
[sudo] password for root:
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
Problem: 1: the installed audit-4.0-3.3.x86_64 requires 'audit-rules = 4.0', but this requirement cannot be provided
deleted providers: audit-rules-4.0-179.22.x86_64
not installable providers: audit-rules-4.0-3.3.x86_64[download.opensuse.org-oss]
audit-rules-4.0-3.3.x86_64[openSUSE-20240725-0]
Solution 1: install audit-4.0.2-180.1.x86_64 from vendor obs://build.opensuse.org/security
replacing audit-4.0-3.3.x86_64 from vendor openSUSE
Solution 2: install audit-rules-4.0-3.3.x86_64 from vendor openSUSE
replacing audit-rules-4.0-179.22.x86_64 from vendor obs://build.opensuse.org/security
Solution 3: keep obsolete audit-rules-4.0-179.22.x86_64
Solution 4: break audit-4.0-3.3.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c):
Is there some recommended procedure to follow in case of a ‘requirement not provided error’ being thrown by ‘zypper dup’?
This comes up often lately relating to different random packages - this time it’s audit-4.0 - and I’m wondering how to best deal with such a situation in general.
… I guess so. Because the official repos lack a crazy lot of necessary packages (like mulitmedia, codeblocks, etc.).
What is the best way to clarify my confusion about which repos go together without issues and which cause trouble? https://en.opensuse.org/Package_repositories is vague about that at best…
Only “Official Repositories” “go together without issues” because they are tested before release. Any other repo is prone to issues sooner or later.
Some of them offer packages that are not in any official repo (Nvidia, AMD come to mind) and are less likely to give conflicts, but may occasionally be slower to catch up e.g. when a new major kernel version appears.
All those that offer different versions of packages that are also on the official repos may give conflicts every now and then: especially KDE, Gnome and the like, even Packman at times. Anybody using one of them should know what they are doing and be prepared to solve the occasional conflict.
Personally I restrict those to the bare minimum needed, e.g. installing only selected packages and not doing the complete “vendor switch”.
What is the best was to get an ‘global’ overview of which packages are provided by several repos?
That is exactly what I am aiming for. I’m still confused about all the repos in detail (well I do have a basic idea) and what are the differences of the same package but from different repos…
I tried to do that as well but that ‘bare minimum’ turned out to pull in a huge swath of dependencies and those dependencies are prone to cause trouble.
It’s all one big mess… (for someone who does not know (yet) exactly what he is doing)
A standard install with only the “official” repositories is perfectly functional for most users.
If you want to play some restricted formats (currently only .mp4 videos among formats in wide use) you need some codecs from the “Packman Essentials” repo: some ffmpeg for Firefox, a couple of gstreamer for Gnome native players, vlc-codecs on KDE. Those may call in some dependencies, but what I see is a dozen packages or even less.
Anything else is from “special needs” in my view, as in “something most users don’t need”, and you should ask “do I really need this?” before adding random repos.
A few examples to show what I mean: multimedia:/proaudio science hamradio
Then there are repos used to try/test new or development versions of what is already in the “official” repos and those should not be used unless you are, really, “trying or testing” and expecting some snags here and there. Those include most repos titled Gnome, KDE, Mate, Cinnamon, LibreOffice, Mozilla and the like or Kernel, Virtualization and the like (the list being too long to be exhaustive here).
Since packages in those repos are already in the official repos, likely in an older version, expect recurring conflicts during upgrades if you have any of those repos enabled, but here, really, “you need to know what you are doing”.
You may occasionally be directed to install selected packages from those repos during debug or to temporarily fix an issue waiting for a fixed package to reach the official repos, but in such cases it is good practice to disable the repo after testing to avoid conflicts and further problems during upgrades.