Audit-4.0-3.3.x86_64 requires 'audit-rules = 4.0', but this requirement cannot be provided

Here we go again…

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.

You are using arbritrary developement repos. You as admin need to decide what to do.

… which means either solution 1 or 2 depending on your needs since audit and audit-rules should match and come from the same repo…

… 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”.

Thanks for the clarification.

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)

I had this issue, too. On my system the following packages related to audit were installed:
openSUSE:

  • audit
  • libaudit1
  • libaudit1-32bit
  • system-group-audit

build.opensuse.org:

  • audit-rules
  • libauparse0
  • python3-audit

I switched all packages to openSUSE without any problems, the system still works and the issue is gone, now.

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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.