#1163 closed enhancement (fixed)

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

Reported by: robert@… Owned by: pesco
Priority: normal Milestone:
Component: OTR Version: 3.2.1
Keywords: patch Cc:
IRC client+version: Client-independent Operating System: Public server
OS version/distro: RHEL 5 and 6


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.

Attachments (0)

Change History (10)

comment:1 Changed at 2014-07-06T16:20:16Z by robert@…

Nice, the anti-spam protection dislikes the patch, thus here is the link:

comment:2 Changed at 2014-07-07T09:10:49Z by 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!

comment:3 Changed at 2014-07-07T09:10:57Z by dx

Keywords: patch added

comment:4 Changed at 2014-07-07T09:14:36Z by 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.

comment:5 Changed at 2014-07-07T12:13:28Z by robert@…

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

comment:6 Changed at 2014-07-07T12:20:16Z by 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.)

comment:7 Changed at 2014-07-07T12:41:13Z by 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!

comment:8 in reply to:  7 Changed at 2014-07-07T15:48:14Z by 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.

comment:10 Changed at 2015-10-13T01:15:23Z by dx

Resolution: fixed
Status: newclosed

Not sure why I didn't close this before.

Modify Ticket

as closed The owner will remain pesco.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.