[PKG-Openstack-devel] Dependency on ‘python-lockfile’: API breakage in version 0.9

[Thomas Goirand]

On 11/26/2014 09:29 AM, Ben Finney wrote:
> Howdy,
> 
> You are maintaining a package with a dependency on ‘python-lockfile’.
> That package will soon upgrade to a backward-incompatible version, and
> dependent packages need to accommodate this compatibility breakage.
> 
> The ‘lockfile’ upstream changed the API as of version 0.9
> <URL:https://code.google.com/p/pylockfile/source/browse/trunk/RELEASE-NOTES>,
> and dependent Python code will not work until it uses the current API.
> 
> As I see it, there are several actions to take:
> 
> * Upload a new version of your package which declares a versioned
>   dependency on “python-lockfile (<< 0.9)” to make the API
>   incompatibility explicit.
> 
>   This informs the dependency manager that the package only works with
>   older ‘python-lockfile’ versions, and means the package cannot be
>   installed with a newer ‘python-lockfile’.
> 
> * Work with your package's upstream to have the code support
>   ‘lockfile’'s current API, if it doesn't already. Encourage them to
>   release a new version with that support.
> 
> * Package the new version in Debian, declaring a dependency on
>   “python-lockfile (>= 0.9)”.
> 
> If you've already done this, great! Please let me know so that I can
> keep track of which packages are affected.
> 
> I intend to release ‘python-lockfile’ at version 0.9 or later. I would
> prefer to have dependent packages ready for this API change. If you
> need help, please ask.

I'm sorry, but aren't we in the deep freeze phase of Jessie? What's your
plan exactly? Release a new package in Debian Experimental? Even if you
do that, I don't think it's a good idea to do it now. People (like me)
are uploading to Experimental because they can't do it in Sid, so having
a new package in there may break things.

Can't you update lockfile after the release of Jessie?

Also, could you give a brief sum-up of the API breakage between <<9 and
>= 9? Would it be possible to work with upstream to avoid such breakage?

It doesn't seem reasonable at all to me to have API breakage in a small
500 lines library containing only 12 classes and 26 methods, while the
Linux kernel (which is far more complex) doesn't break the userland at
all, as a rule. I believe it's our role as a distribution to work with
upstream to avoid such craziness. Maybe upstream doesn't understand the
importance of a stable API, and it would be worth explaining how bad
such breakage is. What is your view here?

Cheers,

Thomas Goirand (zigo)