Bug#692327: libotr: Please provide libotr2

severity 692327 important
thanks

On Mon, Nov 5, 2012 at 1:32 AM, Dmitrijs Ledkovs <xnox@debian.org> wrote:

Package: libotr, release.debian.org
Severity: serious
User: release.debian.org@packages.debian.org
Usertags: transition

Recently libotr has been updated to version 4.x.x with binary package
name libotr5.

By the looks of things, it was done because of pidgin-otr package which
now requires libotr5.

It was done because upstream has updated their source and the new libotr is incompatible with the old one.

But this means an un-coordinated transition has started, as there are 6
other packages that build-depend on libotr2-dev and all of them fail to
build from source against libotr5-dev:

I was not aware a "coordinated transition" was necessary for such a small library. I'm under the impression the release team has bigger fish to fry right now.

* bitlbee
* irssi-plugin-otr
* kdenetwork
* mcabber
* psi-plus
* python-otr

Please do something to resolve this. Input from release team is highly welcome.

Possibilities I can think of are:
* revert libotr source package to 3.2.1-1 & upload libotr5 (4.0.0-2) source package

No. Upstream will not provide maintenance for 3.x.

* keep libotr source package as it is, upload libotr2 (3.2.1-1) source package

No. See above.

* provide patches/NMUs to fix FTBFS for above packages when built
against libotr5-dev.

How about letting their upstreams doing their jobs? libotr 3.x is gone, I'm sure they'll wake up eventually.

Usually disruptive uploads like this one, should be co-ordinated with
the release team with a transition bug, and staged in experimental to do
test rebuilds.

I don't see how this is a serious bug.
1) it only affects unstable (which is named so for a reason)
2) libotr5 has been sitting in experimental for quite a while, and upstream devs have been quite vocal about the transition
3) libotr5 can be installed alongside libotr2

kthxbye

--
Thibaut VARENE
http://hacks.slashdirt.org/