HEADSUP: json-c SONAME BUMP

[Simo Sorce]

On Mon, 2014-07-28 at 12:02 -0400, Miloslav Trmač wrote:
> ----- Original Message -----
> > On Mon, Jul 28, 2014 at 08:53:53PM +0800, Christopher Meng wrote:
> > > As upstream didn't seriously consider the API breakage, json
> > > 0.11->0.12 brings an issue of one function which is deprecated from
> > > now on. This has caused bug 1123785
> > 
> > > so I will bump the soname manually
> > 
> > I'm sorry, wat???
> > 
> > This is not your decision to make as packager. What will you do when upstream
> > bump the soname? Do soname +1 again?
> > 
> > If the udpate broke packages:
> <snip>
> > b) if it was only applied to rawhide (which to my
> > understanding it should have), then just inform the maintainers of the
> > affected
> > packages that they have to rebuild or ask to do so yourself.
> 
> No, that would completely defeat the point of the soname.  If upstream
> won’t use sonames or symbol versioning, it’s better for Fedora to
> patch the software to use them properly, even if it means having to
> continue to patch it.  IIRC we do have various packages that have to
> do this.

If upstream is not using soname bumping then it would probably be better
for fedora to use symbol versioning rather than arbitrarely bumping so
names ...

> (The tradeoff here is that if we don’t fix the soname/versioning
> usage, locally-compiled software of _Fedora’s_ users, and packages in
> _Fedora_ that didn’t get updated, are silently broken; 

it is a very bad tradeoff, esp given symbol versioning can be used to
avoid that.

> if we do fix the soname/versioning usage, other people’s _non-Fedora_
> packages may not be installable on Fedora easily.  The best thing of
> course is to have upstream use sonames/versioning correctly, and have
> nothing broken; but if that’s not possible, a Fedora-specific fix does
> seem much more preferable.)

Making upstream aware of the problem and sending patches is always
preferable. Educate them so the problem is solved once and for all.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York