review request for libpst

[Michael Schwendt]

On Thu, 09 Apr 2009 13:05:14 -0700, Carl wrote:

> 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?

You're trying to optimise the dependency for cherry-picking of package
builds. With an ordinary library package and strict libtool versioning it
would be possible to do it that way, but pkg %{name} and pkg %{name}-libs
are built from the same src.rpm anyway, are published together, and
depsolvers typically look at only the latest release of a pkg.

With your less strict dependency, one could "yum update %name-libs" to a
higher %version while keeping an older installed %name pkg. As I said, the
'>=' dependency is less accurate than '='. The old %name pkg might suffer
from bugs -- vulnerabilities even, with the %name-libs %changelog mentioning
a fix but the %name pkg being too old.

There is no logical AND involved in depsolving a set of dependencies,
as far as I know. You've got two dependencies,

  1.)  %{name}-libs >= %{version}-%{release}
  2.)  libpst.so.2

which theoretically could be satisfied by two separate sets of packages.
It can happen that the depsolver first resolves dep 1, which could be
satisfied by a pkg libpst-libs that provides libpst.so.3 (!), and then the
depsolver finds libpst.so.2 in a different package, e.g. libpst2-libs, a
package that can be installed in parallel. If the pkg that satisfies dep 1
provides the stuff needed by dep 2, there is not much benefit, because
it's the latest release of %name-libs in the repo that satisfies the
'greater or equal' anyway (and hides all older %name-libs pkgs as it
is supposed to update/upgrade them).

> > 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).

A non-versioned explicit Requires on a package name is not better than the
automatic dep on the SONAME. It's worse -- if you keep package renaming
and library moving in mind.

> 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. 

The only explicit Requires that's plausible for subpackage inter-package
dependencies is '... = %version-%release" to require exactly the
subpackages built from the same src.rpm. This strict dependency makes
sense for all a src.rpm's subpackages with inter-package dependencies on
eachother actually. Documentation subpackages don't need such a dep at
all, if they can be displayed with a reader from an external package.

Rule of thumb as I see it: If there is an inter-package dependency between
sub-packages built from the same src.rpm (e.g. library interfaces,
command-line/tool interfaces, data files, files needed at run-time), make
the dependency explicit and a strict "... = %version-%release".
 
> 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,

No automatic rebuilds of apps are done if a build dependency is upgraded.

If "other-pkg" really needs a minimum version of a library package at
run-time, that must be added as an explicit Requires, unfortunately. With
a spec file comment explaining the necessity. Explicit minimum versions
for BuildRequires and Requires increase the package maintenance overhead
(and require developers and packagers to keep their "configure" checks and
minimum versions very accurate and in sync). Package maintainers must be
careful with library version upgrades -- and hope that users apply all
Updates regularly. ;-)