Library versioning vs RPM versioning

[Michael Schwendt]

On Wed, 19 Oct 2005 08:34:03 +0200 (CEST), Linus Walleij wrote:

> Need to get this clear, out of curiosity...
> 
> If say, foo-1.0-1.rpm provides a library as /usr/lib/libfoo.so.1 and then 
> we say foo-1.1-1.rpm is released providing /usr/lib/libfoo.so.2.
> 
> Then, if there is one package bar-1.0.rpm that needs 
> /usr/lib/libfoo.so.1 (and has Requires: foo = 1.0 in its spec) and 
> another baz-1.2.rpm that needs /usr/lib/libfoo.so.2 (and has Requires foo 
> = 1.1 in its spec), what happens from a user point of view?

The entire scenario is flawed.

First of all, the dependency on libfoo.so.1 and libfoo.so.2 ought
to be automatic through rpmbuild's SONAME requirements. No manual
"Requires: foo = ..." must be added in this case.

Secondly, what would the -devel packages for your two versions
of "foo" be called? Obviously, it cannot be just foo-devel.
 
> As I understand it, as long as no files collide you could have both 
> foo-1.0-1 and foo-1.1-1 installed and satisfy both dependencies. So 
> using command-line rpm that's all pretty easy.

Not for rpm -Fvh or -Uvh either.

> (And this is a strong argument for keeping old versions of packages in the 
> repository, then, atleast stuff providing libraries, since someone who 
> want to install both "bar" and "baz" will need two versions.)

If two different versions of a library are needed in the repository
maintainers' point of view, they ought to be given a distinct package
name and be made parallel installable, like foo1-1.0-1.i386.rpm and
foo-2.0-1.i386.rpm, for instance. This would also fix the build
requirements situation => foo1-devel and foo-devel to distinguish
between the two APIs.