On Thu, 09 Apr 2009 10:08:33 -0700, Carl wrote:
> Thanks to everyone for their comments. Thinking about this dependency
> from the main libpst package to the -libs subpackage, it seems that we
> should have
>
> Requires: %{name}-libs >= %{version}-%{release}
>
> in the main package.
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.
Since the tools/apps in libpst main pkg are linked with the library
from within the same src.rpm, you rather want to depend on the
exact %version-%release of the -libs package.
Actually, this is likely the reason for the subpackage Requires
guidelines. ;) Non-library packages are not affected.
External packages linked with libpst are not affected either and can
rely on the automatic SONAME dependency.
> Currently, the soname is libpst.so.2 with libtool
> - -version-info 2:0:0 and library name libpst.so.2.0.0. If we add some
> interfaces, but don't change any existing interfaces, then
> - -version-info goes to 3:0:1 and the soname stays at libpst.so.2 and
> the
> library name is libpst.so.2.1.0. We need some mechanism to capture that
> dependency. Yes, this version of the executables needs libpst.so.2, but
> it won't run with the original libpst.so.2.0.0. How is this sort of
> dependency handled in other packages? I think the above Requires solves
> that within this package.
The latest published package release of libpst implements the
needed library interfaces for anything that depends on libpst.so.2.
Older release of libpst are not available anymore.
> It would also be nice to allow installing multiple (matching) -devel
> and -libs packages for different major versions.
That would only be possible with changed package %name, relocated
install locations. Or else the packages would conflict or upgrade
eachother.
>
> If we change interfaces, with -version-info up to 4:0:0, soname is
> libpst.so.4, library name is libpst.so.4.0.0, and the headers go into
> /usr/include/libpst-4. Is there anything here that would prevent
> parallel installs for the so.2 and so.4 versions?
Yes, the libpst.so symlink from the -devel pkgs.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
