On Wed, 1 Aug 2012, Colin Guthrie wrote:
I have to agree here that something is "funny" in the libattica package
which ultimately helped to contribute to this issue.
e.g. on my system before update (tho' with similar results after):
[colin@jimmy ~]$ rpm -q --provides lib64attica0
libattica.so.0.3()(64bit)
lib64attica0 = 0.3.0-1.mga2
lib64attica0(x86-64) = 0.3.0-1.mga2
[colin@jimmy ~]$ rpm -ql lib64attica0
/usr/lib64/libattica.so.0.3
/usr/lib64/libattica.so.0.3.0
So I can see how this mistake was made and TBH I could have made the
same mistake myself (with the caveat that I likely would not have bumped
the version of someone else's package with out confirming first and that
it should have been obvious from testing and installing the build)
But either way this seems like an issue to fix properly (possibly with
an upstream fix or some modification to the library policy when the
minor version is "presented" like this).
Good catch! Of course it's never the library policy that's wrong. The
library major version is apparently 0.4 so the correct package name is
lib64attica0.3 for the previous one
lib64attica0.4 for the current one
... in the specfile: %define attica_major 0.4
Can the maintainer of this package please fix this?
To find the version to use, look up the 'soname' of the library. I use:
readelf -a /usr/lib64/libattica.so.0.4|grep SONAME
=>
... Library soname: [libattica.so.0.4]
What follows ".so." is the major version of the library.
Christiaan
