libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07)

[Ville Skyttä]

On Wednesday 07 February 2007 14:38, Fedora Extras repoclosure wrote:

> package: amarok - 1.4.4-1.fc5.i386 from fedora-extras-5-i386
>   unresolved deps:
>      libmtp.so.2

Ditto:

> package: amarok - 1.4.4-1.fc5.ppc from fedora-extras-5-ppc
> package: amarok - 1.4.4-1.fc5.x86_64 from fedora-extras-5-x86_64
> package: amarok - 1.4.4-7.fc6.i386 from fedora-extras-6-i386
> package: amarok - 1.4.4-7.fc6.ppc from fedora-extras-6-ppc
> package: amarok - 1.4.4-7.fc6.x86_64 from fedora-extras-6-x86_64
> package: gnomad2 - 2.8.9-2.fc5.i386 from fedora-extras-5-i386
> package: gnomad2 - 2.8.9-2.fc5.ppc from fedora-extras-5-ppc
> package: gnomad2 - 2.8.9-2.fc5.x86_64 from fedora-extras-5-x86_64
> package: gnomad2 - 2.8.9-2.fc6.i386 from fedora-extras-6-i386
> package: gnomad2 - 2.8.9-2.fc6.ppc from fedora-extras-6-ppc
> package: gnomad2 - 2.8.9-2.fc6.x86_64 from fedora-extras-6-x86_64

Linus, was the soname change of libmtp announced somewhere in public 
beforehand?  Why was it necessary push the update to non-devel distros?  
Apologies if I missed the announcement, but based on the above list of 
breakage I'm not alone even within Fedora maintainers, let alone elsewhere.

In case you're not aware of it, yum (more or less by design AFAIK) bumps the 
severity of a single dependency problem among a batch of updates into the 
*sum* of all other problems fixed in the batch, including security ones and 
across all repos, by refusing to install any of them unless the user manually 
cherry picks the packages not affected by the dependency issue separately.  
This is what users of amarok and/or gnomad2 on FC-5 and FC-6 have to deal 
with right now, and maintainers need to take it extra carefully into account 
at all times as long as yum has anywhere near the significant role it 
currently has or is fixed.

FESCO, what's the status of the incompatible package upgrade policy?  I didn't 
find it in Wiki nor the FESCO schedule.  At the very least, instructions how 
packagers must communicate (where, how long beforehand, rationale of the 
update) incoming incompatible upgrades needs to be put somewhere and people 
made aware of it.