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(a)iki.fi>:
>>> On Monday 11 February 2008, buildsys(a)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-b2927ee3158...
>>> (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.
CU
knurd