Re: Adding version constraints in dependencies to avoid bugs
On Thursday, September 15, 2016 11:50:33 PM Thomas Goirand wrote:
> Hi everyone,
>
> Recently, the upload python-cryptography broke pyopenssl, and pyopenssl
> had to be upgraded to support the new python-cryptography (I don't have
> the exact details, but it doesn't mater much here...).
>
> Someone is insisting that I should set the minimum version of
> python-openssl in my packages, just to avoid the bug of pyopenssl. I
> replied that if we were to do so in Debian, the work would be
> exponential, and that this is not what we should do: the bug in
> pyopenssl has been fixed (in a record time, I should also mention), and
> it is my opinion that there's no work required on my package that depend
> on python-openssl.
>
> Am I right that I should do nothing on my packages, or should we
> *really* modify about 54 source packages just to avoid a bug in one of
> the dependencies? What if we have a bug on a high profile package with
> hundreds of reverse dependencies?
>
> Moreover, all versions of pyopenssl are perfectly working with these
> packages. It's just if you don't select well the couple python-openssl +
> python-cryptograhy that there's such an issue. Pushing a higher version
> may potentially add work for backporting to stable (and I maintain the
> backports of 9 of these 54 packages, btw).
>
> What's the view of my Debian buddies here?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> P.S: For those not into python stuff, of course, pyopenssl is the source
> package for python-openssl...
I think it would be simpler and more correct for python-cryptography to
declare a breaks relationship with python-openssl, e.g. (in the binary control
stanza for python-cryptography):
Breaks: python-openssl (<< FIRST_NOT_BROKEN_VERSION~)
That should ensure python-openssl is upgraded with python-cryptography without
having to touch an entire stack of rdepends.
Scott K
Reply to: