On 2023-04-06 10:31, Jan Engelhardt wrote:
As I pointed out before, the ELF data doesn't indicate a minor version for the dependency, only the major version.*That* is the root of the problem. So if it can't be solved at the ELF level, what makes you think at can be solved at the RPM level?
Let me rephrase what I'm saying, because I am not saying that this can't be solved at the ELF level. An ELF binary indicates both the soname required and the set of symbols required within shared objects. It's undesirable to copy both the soname and the individual symbols into rpm dependencies, because the size of the repo metadata and the CPU time and memory required on individual systems to resolve dependencies would massively inflate, so currently a subset of the ELF information is copied into rpm dependencies. For libraries with versioned symbols, that includes the soname and the versions in that library which are required by the packaged binary. For libraries without versioned symbols, it's just the soname. (and, technically, both may include a 64bit marker) For libraries with versioned symbols, that's enough to reliably generate accurate dependency information, but for the majority of libraries (which don't provide versioned symbols), it isn't. For those libraries, rpm has less information available than the actual ELF binaries, and not enough to reliably update dependencies, leading to problems like the one that started this thread. For those libraries, we're discussing how best to add a version to the dependency information in order to enhance the information that rpm has, without massively inflating it.