review request for libpst

[Carl Byington]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



> That would not be more accurate, because you could not guarantee that
> _any_ libpst-libs package with a higher %version would be compatible.
> Especially not if %version has nothing to do with the libtool library
> version.

The combination of 'Requires: %{name}-libs >= %{version}-%{release}'
with the automatic soname dependency would only be satisfied by a
version of the -libs package that 1) implements libpst.so.2, and 2) is
at least as recent as the current version. Anything satisfying both of
those conditions must implement all of the interfaces needed by the
current executables. Or am I missing something?


> External packages linked with libpst are not affected either and can
> rely on the automatic SONAME dependency.

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.

In any case, I think that the main libpst package should Require the
- -libs subpackage using the same (version or not) line as in any other
package that depends on libpst-libs. 

Or is it the case that these sorts of dependencies are handled by the
repository and fedora build system? In the sense, that if we upgrade to
- -version-info 3:0:1 and rebuild libpst, and the other package is built
against that new version, then a user with an existing old version from
(a) doing 'yum install other-pkg' will automatically get the newer
libpst, even though the soname dependency would seem to be satisfied by
the existing libpst.so.2 on that end user system. I don't see any
mechanism in place to do that, but it would be nice.

The other alternative is that *any* change to the interface, even just
adding a new interface, results in an soname bump.


> Yes, the libpst.so symlink from the -devel pkgs.

Ok, I will ignore the parallel install issues for now (unless you have
a suggestion for a fix). 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFJ3lS4L6j7milTFsERAjtfAJ9cBehp0PvqEyP6lZHUO6KeFsHQ7QCfTjgS
GWywg4bKsyBQcfJcZi/F5bM=
=uySC
-----END PGP SIGNATURE-----