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 uniqueIn /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
Regards
2013/3/25 Michael Schwendt <mschwendt@xxxxxxxxx>
On Mon, 25 Mar 2013 01:44:49 +0100, Kevin Kofler wrote:Why is that incorrect?
> 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
Huh? Who has made that assumption? The previous soname was libcfitsio.so.0,
> (based on
> the wrong assumption that he would be setting the soname to just
> libcfitsio.so.3, which would of course be wrong).
which has been a bad choice for an API/ABI that changes so frequently.
That is misleading. IMHO.
> Just set the soname and the fully-versioned name both to
> "libcfitsio.so.%{version}".
That isn't done, however, so currently no patching is necessary.
> >> 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.
"Cleaner"? That's all? Then this is a superfluous discussion. It doesn't
> >> 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.
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
