RFE: Finer-grained symbol dependencies

[Conan-Kudo]

Historically speaking, RPM's library dependencies have been only covered the soname.

However, this has bitten us from time to time when the actual symbols have changed. Some distributions solve this by actually generating dependencies against both the version/soname and the library symbol name.

I suggest that elfdeps be extended to offer a mode to generate finer-grained dependencies.

For example, suppose package libfoo provides libfoo.so.1, and bar depends on it.

libfoo.so.1 provides two symbols do_foo and __do_baz with a symbol version FOO_1.0.

Classically, this means that libfoo would have the following Provides:

libfoo.so.1()(64bit)
libfoo.so.1(FOO_1.0)(64bit)

And bar would require these two symbols. But if __do_baz is deleted, bar would be broken if it used that symbol or depended on it in some way. Unfortunately, it'd still be installable...

However, with an enhancement, the libfoo package would have the following Provides:

libfoo.so.1()(64bit)
libfoo.so.1(FOO_1.0)(64bit)
libfoo.so.1(do_foo@FOO_1.0)(64bit)
libfoo.so.1(__do_baz@FOO_1.0)(64bit)

Then, bar would have the following Requires:

(libfoo.so.1()(64bit) with libfoo.so.1(do_foo@FOO_1.0)(64bit))
(libfoo.so.1()(64bit) with libfoo.so.1(__do_baz@FOO_1.0)(64bit))

This effectively guarantees that the symbol is tracked in the dependency itself.

[ignatenkobrain]

We are trying to do something similar with @legionus . We will come back with some results after some time ;)

[mlschroe]

First, I don't see why you need the rich deps here. Wouldn't a libfoo.so.1(do_foo@FOO_1.0)(64bit)) requires be enough?

Then, wouldn't your proposal mean that over time you'll have a provide for every symbol? That'll be quite some burden on the metadata size and dependency solver setup. If you really want something like this you should look at altlinux's support of set-versions dependencies (IIRC).

[Conan-Kudo]

My understanding is that set-versions imposes the same requirement (provide for each symbol), only that it's inscrutable to the user because it's hashed rather than in user-comprehensible form.

You're correct that it may not necessarily require rich deps, though. I was thinking of cases where a library may provide multiple symbol names and do funny things (for example, I believe libsystemd did this at one point).

[mlschroe]

No, the point of set-versions is that you only have one provides/requires for all of the symbols. This means that it's a somewhat probabilistic method, there's some small chance it will not detect a missing symbol.

[pmatilai]

Yeah set versions is no doubt clever. Problem is it's too clever for my taste. Call me a chicken anytime you like but I'm not going to pull this thing in: http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=lib/set.c;h=9474a2ee6d7c9ce321d131cc310bfb4e80bdc6e4;hb=HEAD

[svpv]

@pmatilai So what do you mean by too clever? Actually, I've been thinking about splitting the implementation into a few pieces, each doing only one thing. So how about this API: rpmss.h? Does it look more sensible? (The implementation is still a bit of a mess, but if we could agree on the API...)