Bug#692327: libotr: Please provide libotr2

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

On 05/11/12 10:58, Thibaut VARENE wrote:
> severity 692327 important
> thanks

>
> I don't see how this is a serious bug.

Currently libotr2* are not build from any source package in sid.
That means that any packages depending on it cannot transition into
testing (if it was not frozen).

Is there such a not frozen package?

That also means that libotr5 cannot transition into testing (if it was
not frozen).

That was never the plan, considering libotr5 got uploaded (purposefully) after the freeze.

Sure it's not a problem. But if the existing status quo is kept, neither
libotr5 nor the new pidgin will make it into wheezy nor jessie.

That it won't make it to wheezy, I can see why and that's intended. I don't see how jessie is affected. My package is fine, pidgin-otr is fine, and they both work. The other packages that depend on libotr need to update, and again, I don't see why they wouldn't considering that libotr5 is the NEW libotr. Or are you suggesting that for the sake of the argument, all dependencies are going to stick using libotr2 just to piss me off?

Your package is not fit for inclusion in a stable release.

Really? That's news to me.

Given your position, maybe you should file removal requests for package
that still depend on libotr2.

I don't see a need for that when all it takes to "resolve" this "issue" is an update from the dependent packages. If we were to request package removal everytime a new library breaks its API, things would get pretty ugly (and by that I mean, more than they usually are).

In Ubuntu, I have uploaded libotr2 source package to transition libotr5
into testing and keep all applications that use libotr2 or libotr5
installable and releasable.

Very nice. Enjoy dealing with the innevitable mess this will provoke.

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