Hello All!
I just prepared to update wavpack to latest version (4.50). Among some
bugfixes it introduces minor soname-bump (
/usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 )

Keeping in mind my infamous upgrade of Xerces-C from 2.7.0 to 2.8.0, I
decided to secure against similar issues and want to ask - whether
someone has objections against this upgrade? If not, then I'll upgrade
wavpack ASAP.
--
With best regards!

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 18 Jun 2008 16:37:52 +0400, Peter Lemenkov wrote:

> Hello All!
> I just prepared to update wavpack to latest version (4.50). Among some
> bugfixes it introduces minor soname-bump (
> /usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 )
>
> Keeping in mind my infamous upgrade of Xerces-C from 2.7.0 to 2.8.0, I
> decided to secure against similar issues and want to ask - whether
> someone has objections against this upgrade? If not, then I'll upgrade
> wavpack ASAP.

What is the soname, libwavpack.so.1 or libwavpack.so.1.0.2?

--
Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8
loadavg: 1.36 1.41 1.57

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, Jun 18, 2008 at 04:37:52PM +0400, Peter Lemenkov wrote:
> Hello All!
> I just prepared to update wavpack to latest version (4.50). Among some
> bugfixes it introduces minor soname-bump (
> /usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 )

The soname stays at "libwavpack.so.1", so technically it's not a
soname bump . Should be safe to upgrade.

--
Miroslav Lichvar

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/6/18 Peter Lemenkov <lemenkov@gmail.com>:
> Hello All!
> I just prepared to update wavpack to latest version (4.50). Among some
> bugfixes it introduces minor soname-bump (
> /usr/lib/libwavpack.so.1.0.1 >> /usr/lib/libwavpack.so.1.0.2 )

You can see if upstream has bumped the soname by running this

# readelf -a /usr/lib64/libwavpack.so.1.0.1 |grep SONAME
0x000000000000000e (SONAME) Library soname: [libwavpack.so.1]
Where the soname is libwavpack.so.1

On the other hand you can check if ABI has actually changed with
rpmsodiff wavpack-4.41-1.fc10 wavpack-4.50-1.fc10

Now i'm not really sure of how can be read this output, since there
might be symbol that have changed, but was not accessible from a
public API (so they are symbols used internally which doesn't produce
any ABI incompatibility).

The case where ABI breaks is when symbol are removed that might be
used by any dependent application.
(As I expect). When symbols are only added, this would mean that ABI
is preserved and the dependent application can optionally be rebuilt
to use theses new symbols (if they are somehow used within the
dependant application).

It would be nice to have this kind of check from a wiki page. I only
find thoses pages on the wiki, related to this subject.
http://fedoraproject.org/wiki/PackageMaintainers/CommonRpmlintIssues
http://fedoraproject.org/wiki/PackageMaintainers/PackagingTricks#Application_binary_interface_chang es_.28controversial.29


Nicolas (kwizart)

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list