Carl Byington wrote:
> How does that work in the case of
>
> a) early version with -version-info 2:0:0, soname .2, library .2.0.0
> b) newer version with -version info 3:0:1, soname .2, library .2.1.0
> c) other package built against the newer version with automatic
> dependency on soname .2
>
> User installs the early version from (a) which provides soname .2, and
> other package (c) which depends on soname .2 - but really needs library
> 2.1.0.
>
> If the other package just 'Requires: libpst-libs' without any version,
> it would seem to be satisfied by the early version from (a). It seems
> that the other package would need to add some >=release.version to that
> requires. If so, then the main libpst package should also use that same
> Requires.
It doesn't. :-)
That's one of the limitations with the soname dependencies. Some packages
have explicit versioned dependencies when such a relation is known, but in
most cases it isn't and so there's no such dependency, the user is just
expected to upgrade everything (which will replace a with b), not just the
package c.
The only way you can get RPM to autodetect dependencies without soname bumps
is with symbol versioning. If you can get upstream to use symbol versioning
on the platforms which support it (e.g. Fedora (on all architectures)) to
mark each symbol with the version it was first introduced in (or if you ARE
upstream and can do that change there), then RPM will add automatic
dependencies based on those and solve this problem. Note that for this to
work, there is NO NEED to actually have more than one version for any given
symbol! So this can be done without introducing any non-portability, the
symbol versioning would just be used on the platforms where it is
supported. (In other words: such a use of symbol versioning would really be
symbol version-marking, not versioning.) But upstream needs to support it,
most don't, unfortunately. (One warning though: versions should only be
added to NEW symbols. Adding symbol versions to existing symbols is an ABI
change and thus needs a soname bump.)
Examples:
1. unversioned symbol: foo
* contains no version information whatsoever
* RPM has no way to know when foo was first introduced
2. versioned symbol: foo@LIBBAR_2_1_0, foo@LIBBAR_2_2_0
* symbol versioning as used by glibc
* multiple versions of the symbol
* old programs use the old version of the symbol,
newly-rebuilt ones use the new version
* usually a bad idea, as rebuilds magically change the program's behavior
* not portable, because not all platforms support symbol versioning
* different functions should have different names!
3. version-marked symbol: foo@LIBBAR_2_1_0 (and no other foo@* symbol)
* conservative use of symbol versioning
* contains version information which RPM can use for automatic deps
* programs using foo will have a libbar.so.2(LIBBAR_2_1_0) autodep
* on OSes without symbol versioning, just foo (as in 1.) will be used
* as in 1., the function foo must remain binary compatible
The solution 3. is what I'm suggesting to use. RPM autodeps would be much
safer if all upstream projects used that.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
