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
