(CC: debian bugs) On Mon, Aug 25, 2014 at 08:50:17AM -0700, Jeremy T. Bouse wrote: > @hlieberman Even if I (the python-paramiko maintainer) get this patch > included and uploaded in a fixed version bzr will still conflict because the > bzr maintainer team decided to put a "Conflicts: python-paramiko (>> 1.12.0)" > into the debian/control which doesn't help matters just exacerbates the > problem. I'm sitting here in the DC14 Hacklab working on packaging issues and > have discussed that move with several other DDs who think it was a poor move > on the part of the bzr team.
This is a regression in paramiko, and this fix is a trivial and non-risky change. Why can't this bug be fixed in the paramiko package directly for the time being, why does it have to wait to be fixed in upstream? I submitted a patch for this in June. That would have allowed the bug to be fixed in a timely manner without, preventing the removal of bzr and a lot of other packages from testing without any intervention from us: % apt-cache rdepends bzr python-bzrlib | grep -v "|" | uniq | wc -l 49 A Conflict was the quickest way in which I could unbreak bzr for its users considering the paramiko Debian bug was stalled. I agree this is not an ideal workaround - but I was hoping paramiko would soon be fixed, after which I could remove the conflict. An alternative workaround for me is to patch bzr to disable its paramiko support if it finds a broken version of paramiko. If this paramiko bug stays open for much longer then I'll see if I can do that instead. If there's anything further I can do to help get this bug fixed in paramiko (upstream or in Debian), please let me know. Jelmer -- Jelmer Vernooij <jel...@samba.org> - https://jelmer.uk/
signature.asc
Description: Digital signature
