xerces-c soname bump

Thorsten Leemhuis fedora at leemhuis.info
Tue Feb 12 10:58:23 UTC 2008

On 12.02.2008 11:33, Michael Schwendt wrote:
> On Tue, 12 Feb 2008 09:45:20 +0100, Thorsten Leemhuis wrote:
>> On 12.02.2008 09:11, Peter Lemenkov wrote:
>>> 2008/2/12, Ville Skyttä <ville.skytta at iki.fi>:
>>>> On Monday 11 February 2008, buildsys at fedoraproject.org wrote:
>>>>> Packages built and released for Fedora EPEL testing/5: 7
>>>> [...]
>>>>>     xerces-c-2.8.0-1.el5
>>>>> Packages built and released for Fedora EPEL testing/4: 5
>>>> [...]
>>>>>     xerces-c-2.8.0-1.el4
>>>> This is a soname bump from libxerces-c.so.27 to libxerces-c.so.28, and looks
>>>> like it would break at least enigma, gdal, ovaldi, perl-XML-Xerces and
>>>> xalan-c, not to mention local packages and other local builds.
>>>> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-b2927ee315835820eecc0883d05df0e1658ac388
>>>> (soname bump is an ABI change)
>>>> I haven't seen even a "HEADS UP" mail about this.
>> Hopefully sooner or later Fedora and EPEL get tests script that notice
>> such things before they hit the repo :-/
> Remember that with Plague successful builds enter the buildroot repos,

Sure, but the plan is to move to Koji and Bodhi over the next few
months, so this problems vanishes, as Koji handles things differently.

> so
> even if they are not pushed, they can break the buildroots and can also
> cause other builds to become incompatible meanwhile. It's better if
> maintainers check for ABI- and API-breakage prior to building such
> packages.

Of course. But it seems to me that it doesn't work perfectly (¹) -- it's
not the first time that a problem like this one comes up in Fedora or
EPEL. So afaics we need to remind people somehow explicitly that they
might break deps when they build a updates that provides a lib with a
different SONAME.

(¹) -- maybe better contributer education could help, but that's
something that should dealt with in Fedora-land, as it's not really a
EPEL specific problem

> Especially, since a repoclosure check would only noticed changed
> SONAMEs and not other changes in a library interface (such as removed
> symbols, signatures).

Agreed. But note that I didn't actually mean repoclosure here -- more a
diff between the output of "rpm -qp foo.rpm --provides" between the old
and the new package and a heads up to everyone (or something else; maybe
even put the rpm aside temporary) if a SONAME changed.


More information about the epel-devel-list mailing list