New cfitsio 3.330 in Rawhide and F19 (take 2)

[Sergio Pascual]

I have written cfitsio upstream, requesting that they include a soname in
the library.

Regarding our current discussion, the only requirement is that the soname
is unique
for each release. This comes for the infamous function call that checks the
library version at runtime. In this sense,

libcfitsio-3.340.so.0 and libcfitsio.so.3.340 are equally valid.

In /usr/lib there are lots of libraries with different versioning schemes.
Some include the package version, some not. We have even a library that
includes fc18 in the soname,

$ objdump -p /usr/lib64/libopcodes-2.23.51.0.1-6.fc18.so|grep SONAME
  SONAME               libopcodes-2.23.51.0.1-6.fc18.so

I feel reluctant to rebuild the package and all dependant packages now just
to remove the .0, that is harmless. I will remove it in the next release.
Hopefully the soname will be provided by upstream then.


Regards


2013/3/25 Michael Schwendt <mschwendt at gmail.com>

> On Mon, 25 Mar 2013 01:44:49 +0100, Kevin Kofler wrote:
>
> > Michael Schwendt wrote:
> > > "Standard" versioning is not beneficial here at all. As explained
> before,
> > > here the full version is part of the SONAME. Not just the major
> version.
> > > libcfitsio.so.3.330 would be incompatible with libcfitsio.so.3.340 as
> > > mentioned in a later post by Sergio (on 2013-03-22) already. There is
> > > no common libcfitsio.so.3 that would be downward compatible.
> >
> > But there's no rule that says that the soname has to be libcfitsio.so.3
> > (well, there is if the package builds using libtool, but e.g. CMake
> allows
> > any arbitrary soname, and it also correctly handles the case where the
> > soname is the same as the fully-versioned name). In cfitsio's case, the
> > makefile commands writing the library are handwritten (i.e. don't use
> > libtool) and thus also allow an arbitrary soname; in fact, the soname WAS
> > libcfitsio.so.3.330 before you incorrectly told him to change it
>
> Why is that incorrect?
>
> > (based on
> > the wrong assumption that he would be setting the soname to just
> > libcfitsio.so.3, which would of course be wrong).
>
> Huh? Who has made that assumption? The previous soname was libcfitsio.so.0,
> which has been a bad choice for an API/ABI that changes so frequently.
>
> > Just set the soname and the fully-versioned name both to
> > "libcfitsio.so.%{version}".
>
> That is misleading. IMHO.
>
> > >> The version goes after .so, not before it, unless you want to have it
> > >> also in the symlink, which you explicitly DON'T want here.
> > >
> > > Why not? It would even have been okay to name the run-time lib
> > > libcfitsio-3.330.so with the implicit opportunity to use the same file
> > > as the build-time lib. That would even make it possible to ship
> multiple
> > > releases of cfitsio, since with a non-versioning build-time lib,
> multiple
> > > -devel packages would conflict in their .so symlink (if that one is
> used).
> >
> > But then ALL packages using cfitsio have to be patched to use the
> versioned
> > name. It just doesn't make sense.
>
> That isn't done, however, so currently no patching is necessary.
>
> > >> I know that going back and forth sucks (as everything will have to be
> > >> rebuilt AGAIN), but I think you should really should change this back
> > >> (and you should never have changed it from .so.3.330 to -3.330.so.0 in
> > >> the first place).
> > >
> > > Either naming version would require rebuilds of dependencies for
> version
> > > changes. So, why bother?
> >
> > Because libcfitsio.so → libcfitsio.so.3.330 is just the cleaner scheme
> > compared to libcfitsio.so → libcfitsio-3.330.so.0. Your scheme has 2
> > versions, one of which is always 0, and the devel symlink does not follow
> > the pattern of pointing from foo.so to foo.so.* with the same name foo.
>
> "Cleaner"? That's all? Then this is a superfluous discussion. It doesn't
> make sense to go in circles. What you consider cleaner is just a version
> that pretends that a clean versioning scheme is implemented. The added .0
> does no harm. It would make it possible to change the ABI without bumping
> the library version.
>
> --
> Fedora release 19 (Schrödinger’s Cat) - Linux
> 3.9.0-0.rc3.git1.4.fc19.x86_64
> loadavg: 0.08 0.08 0.07
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130326/c7bf99d4/attachment.html>