library soname ends with 0.0.0 about trng4

[rabauke]

I think this is not a new behaviour. When you want to criticize that actual API changes are not reflected in the soname then you are right, this is a bug. In fact, I never cared much about library version numbering. I am not quite sure, what would be the right numbering scheme. Would

libtrng4.so -> libtrng4.so.19.0.0'
libtrng4.so.19 -> libtrng4.so.19.0.0
libtrng4.so.19.0.0

be more reasonable (for version 4.19 with an API that is potentially incompatible to 4.18)? What do you think?

Heiko

[torquil]

I just reported it in case it was the result of an oversight (since I
had a hunch that the soname had been different before, but I wasn't
sure), so feel free to close the report if you don't want to bother with
it. I'm not an export of library sonames, but your suggestion below
seems reasonable to me. But maybe it is not so important. E.g. I see now
that lots of libraries in Debian Linux use 0.0.0:

$ ls /usr/lib/*.0.0.0
libaccountsservice.so.0.0.0 libcpufreq.so.0.0.0
libgl2ps.so.0.0.0 liblrdf.so.0.0.0
liborcus-mso-0.10.so.0.0.0 libsmf.so.0.0.0
libann.so.0.0.0 libdfalt.so.0.0.0
libgtkhex-3.so.0.0.0 libmfhdfalt.so.0.0.0
liborcus-parser-0.10.so.0.0.0 libuchardet.so.0.0.0
libavcall.so.0.0.0 libedsio.so.0.0.0
libgtkspell.so.0.0.0 libmythes-1.2.so.0.0.0
libportmidi.so.0.0.0
libbs2b.so.0.0.0 libeot.so.0.0.0
libguile-cairo.so.0.0.0 libompitrace.so.0.0.0
libporttime.so.0.0.0
libcallback.so.0.0.0 libexttextcat-2.0.so.0.0.0
libguile-gnome-gobject-2.so.0.0.0 liborcus-0.10.so.0.0.0
libpyglib-2.0-python2.7.so.0.0.0

$ ls /usr/lib/x86_64-linux-gnu$ ls *0.0.0
libapt-private.so.0.0.0 libglapi.so.0.0.0
libmpeg2convert.so.0.0.0 libsigc-2.0.so.0.0.0
libxcb-glx.so.0.0.0
libasan.so.0.0.0 libgoa-1.0.so.0.0.0
libmpeg2encpp-2.1.so.0.0.0 libstartup-notification-1.so.0.0.0
libxcb-image.so.0.0.0
libatk-bridge-2.0.so.0.0.0 libgslcblas.so.0.0.0
libmplex2-2.1.so.0.0.0 libthunarx-2.so.0.0.0
libxcb-present.so.0.0.0
libbonobo-2.so.0.0.0 libgtksourceviewmm-3.0.so.0.0.0
libmpx.so.0.0.0 libtrng4.so.0.0.0
libxcb-render.so.0.0.0
libbonoboui-2.so.0.0.0 libgtop-2.0.so.10.0.0
libmpxwrappers.so.0.0.0 libtsan.so.0.0.0
libxcb-render-util.so.0.0.0
libcap-ng.so.0.0.0 libhunspell-1.3.so.0.0.0
libmu_cfg.so.0.0.0 libtwolame.so.0.0.0
libxcb-shape.so.0.0.0
libcc1.so.0.0.0 libjbig2dec.so.0.0.0
libmu_compat.so.0.0.0 libubsan.so.0.0.0
libxcb-shm.so.0.0.0
libck-connector.so.0.0.0 liblavfile-2.1.so.0.0.0
libnm-gtk.so.0.0.0 libudisks2.so.0.0.0
libxcb-util.so.0.0.0
libcryptui.so.0.0.0 liblavjpeg-2.1.so.0.0.0
libnm.so.0.0.0 libv4l1.so.0.0.0
libxcb-xfixes.so.0.0.0
libdca.so.0.0.0 liblavplay-2.1.so.0.0.0
libpangox-1.0.so.0.0.0 libv4l2rds.so.0.0.0
libxcb-xv.so.0.0.0
libdebconfclient.so.0.0.0 liblightdm-gobject-1.so.0.0.0
libpcrecpp.so.0.0.0 libv4l2.so.0.0.0
libxfce4kbd-private-2.so.0.0.0
libdvbpsi.so.10.0.0 liblogging-stdlog.so.0.0.0
libpolkit-agent-1.so.0.0.0 libv4lconvert.so.0.0.0
libxfce4ui-1.so.0.0.0
libepoxy.so.0.0.0 liblsan.so.0.0.0
libpolkit-backend-1.so.0.0.0 libvisual-0.4.so.0.0.0
libxfsm-4.6.so.0.0.0
libestr.so.0.0.0 liblua5.1-c++.so.0.0.0
libpolkit-gobject-1.so.0.0.0 libwayland-cursor.so.0.0.0
libxkbcommon.so.0.0.0
libfaac.so.0.0.0 liblua5.1.so.0.0.0
libportSMF.so.0.0.0 libwebrtc_audio_processing.so.0.0.0
libxkbcommon-x11.so.0.0.0
libgailutil-3.so.0.0.0 liblua5.2-c++.so.0.0.0
libquadmath.so.0.0.0 libwind.so.0.0.0
libXNVCtrl.so.0.0.0
libgarcon-1.so.0.0.0 liblua5.2.so.0.0.0
libraptor2.so.0.0.0 libwxsqlite3-3.0.so.0.0.0
libzvbi-chains.so.0.0.0
libgarcon-gtk2-1.so.0.0.0 libmjpegutils-2.1.so.0.0.0
librdf.so.0.0.0 libxcb-composite.so.0.0.0
libgck-1.so.0.0.0 libmowgli-2.so.0.0.0
librest-0.7.so.0.0.0 libxcb-dri2.so.0.0.0
libgeany.so.0.0.0 libmp3lame.so.0.0.0
libsecret-1.so.0.0.0 libxcb-dri3.so.0.0.0

:-)

Torquil

On 25/10/15 00:49, Heiko Bauke wrote:

I think this is not a new behaviour. When you want to criticize that
actual API changes are not reflected in the soname then you are right,
this is a bug. In fact, I never cared much about library version
numbering. I am not quite sure, what would be the right numbering
scheme. Would

libtrng4.so -> libtrng4.so.19.0.0'
libtrng4.so.19 -> libtrng4.so.19.0.0
libtrng4.so.19.0.0

be more reasonable (for version 4.19 with an API that is potentially
incompatible to 4.18)? What do you think?

Heiko

—
Reply to this email directly or view it on GitHub
#11 (comment).