Hi Orion,
Thank you for maintaining netCDF-related RPMs for many years.
Probably it is not necessary to write to the whole netCDF group for
libnco-related questions, since I know of no RPM-ized applications
besides NCO that use libnco. Though asking shows due diligence and
I would be delighted to learn I'm wrong :) Unless someone else chimes
in let's omit the group and discuss via 1-on-1 email from now on.
Regarding libnco, yes, NCO automatically bumps the soname version.
But libnco adds symbols nearly every version, resulting in many
backwards-incompatible changes in libnco. The upstream-tracker.org
link you sent seems to count changes in libnco_c++ (which has been
stable as indicated) and not the massive churn in libnco, the main NCO
library. In other words, the apparent stability of libnco is a result
of mis-diagnosis. Only bumping soname when symbols change would
probably still change the libnco soname every single verion.
Unless someone uses libnco in a different RPM application, can we
just keep on bumping the current way? I find it difficult to debug NCO
when the soname does not reflect the executable version. Matching
names mean one fewer source of error. Unless there is impact on other
packages, does EPEL care? Although maybe there's a good reason I'm
unaware of. Happy to adopt a different naming convention if there's
a good reason in your considered opinion.
Finally, my vote is update NCO to 4.3.7 in EPEL.
cz
--
Charlie Zender, Earth System Sci. & Computer Sci.
University of California, Irvine 949-891-2429 )'(
