[ofiwg] post OFI 1.0
Weiny, Ira
ira.weiny at intel.com
Sun May 3 12:55:51 PDT 2015
> On May 1, 2015, at 2:03 PM, Weiny, Ira <ira.weiny at intel.com> wrote:
> >
> > If my vote counts for anything I vote to use the semantic versioning (3
> numbers) and have the package number == the library *.so version.
>
> Sorry, I (strongly) disagree with this idea.
>
> GNU Libtool even (strongly) recommends against making the package version
> equal the .so version number (see
> https://www.gnu.org/software/libtool/manual/libtool.html#Versioning).
>
> .so library versions have an inherently different purpose than the package
> version number (especially when there are multiple .so's in a package).
Do we have multiple .so's with _public_ interfaces in libfabric? I guess we do.
If so then yes I agree with you on keeping the version separate.
But some GNU packages do match the package and *.so version:
15:40:12 > rpm -qa | grep glibc-2
glibc-2.11.3-17.43.1
15:40:39 > rpm -qil glibc | grep 2.11.3
Version : 2.11.3 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
Group : System/Libraries Source RPM: glibc-2.11.3-17.43.1.src.rpm
/lib64/ld-2.11.3.so
/lib64/libBrokenLocale-2.11.3.so
/lib64/libanl-2.11.3.so
/lib64/libc-2.11.3.so
/lib64/libcidn-2.11.3.so
/lib64/libcrypt-2.11.3.so
/lib64/libdl-2.11.3.so
/lib64/libm-2.11.3.so
/lib64/libnsl-2.11.3.so
/lib64/libnss_compat-2.11.3.so
/lib64/libnss_dns-2.11.3.so
/lib64/libnss_files-2.11.3.so
/lib64/libnss_hesiod-2.11.3.so
/lib64/libnss_nis-2.11.3.so
/lib64/libnss_nisplus-2.11.3.so
/lib64/libpthread-2.11.3.so
/lib64/libresolv-2.11.3.so
/lib64/librt-2.11.3.so
/lib64/libutil-2.11.3.so
This makes it pretty easy to see which *.so version is installed.
So this seemed reasonable. Is it just a coincidence that this is true for this version of glibc?
Like I said I realize that fixes to documentation and other things make keeping the *.so version and package version the same harder. So if they are not kept the same I am ok with that. But the semver.org and libtool versions are trying to say the same thing (Version the API) with slightly different meanings for X.Y.Z. From an admin point of view this can get kind of hard to track. I prefer to let libtool versions take precedent for the versioning of the API and backward compatibility.
Ira
More information about the ofiwg
mailing list