Conditionalize support for libotr 3 and 4 (to support both)

[robert@…]

With BitlBee 3.2.2 the support for libotr 3.x was dropped while previously libotr 4.x was not supported at all. However some Linux distributions still shop libotr 3.x while other ship libotr 4.x. So the libotr support should be conditionalized to support both.

[robert@…]

Nice, the anti-spam protection dislikes the patch, thus here is the link: ​http://pkgs.fedoraproject.org/cgit/bitlbee.git/tree/bitlbee-3.2.2-libotr-3-4.patch

[dx]

Oh, interesting patch! However, note that we got awful bugs in the transition to libotr4 in apparently harmless code, so I'm kinda paranoid about touching that code.

Pesco opinion required!

[wilmer]

+1. Better no support than buggy support, for by now pretty stale distros. Especially if that means turning otr.c into an ifdef soup.

Might be better to maintain it as a patch, the OTR code doesn't change much anyway and by the time it does, hopefully you won't have to care about old OTR versions anymore either.

[robert@…]

Uhm, RHEL 5 goes EOL in March 2017, but RHEL 6 goes EOL in November 2020 (and both have libotr 3.x).

[wilmer]

I don't think that's BitlBee's problem though, I don't want BitlBee to have to carry this luggage for another six years for a small group of users.

And more importantly, I assume libotr 3.0 is obsoleted by its authors and I wonder whether at some point it will be considered insecure/unsafe/etc. Are there no libotr 4.0 backports for RHEL[56] yet?

(I do by the way violently agree that the libotr authors are not cool for coming up with such a backward incompatible release, putting up software authors with having to keep track of pretty much two different client implementations altogether.)

[dx]

A better solution I had in mind (seeing how we already got complaints in #bitlbee) is to fork the libotr 3.x based otr.c from 3.2.1, add build scripts, and package it as an external plugin. That way we get a guaranteed-stable libotr 3.x implementation, and no potentially-dangerous #ifdefs all over the code, and it's much easier to maintain for everyone, since the idea is to keep it frozen, just like libotr 3.x. Of course it will get enough testing/updates to keep it working if we break internal ABI/API in the future, but just that.

On the packagers side that would mean having a package like bitlbee-libotr3 as a suggested dependency in distros that don't have libotr4.

Robert + pesco opinion required!

[pesco]

Replying to dx:

A better solution I had in mind (seeing how we already got complaints in #bitlbee) is to fork the libotr 3.x based otr.c from 3.2.1, add build scripts, and package it as an external plugin.

Yeah, something along those lines would definitely be my thinking.

[dx]

There: ​https://github.com/dequis/bitlbee-otr3

Tiny bit of lag.

[dx]

Not sure why I didn't close this before.