On Thu, 30 Aug 2012, Ian Goldberg wrote:
Depending on how it's packaged, the runtime packages may be disjoint
(the shared lib has a different name in each version), but the -dev
package (with the header files) has the same filenames, so you'd be
limited to installing one -dev package at a time.
But it may be that only pidgin-otr in pkgsrc uses libotr; if so it's
easier to just upgrade both at once and leave the old libotr behind.
That would indeed be the easiest thing, if true.
In Fedora/EPEL libort is used by:
[paul@thinkpad ~]$ repoquery -qa --whatrequires libotr
bitlbee-otr-0:3.0.4-3.fc17.x86_64
bitlbee-otr-0:3.0.5-1.fc17.x86_64
climm-0:0.7.1-4.fc17.x86_64
irssi-otr-0:0.3-5.fc17.x86_64
kdenetwork-kopete-7:4.8.3-1.fc17.x86_64
kdenetwork-kopete-7:4.8.5-1.fc17.x86_64
kdenetwork-kopete-libs-7:4.8.3-1.fc17.i686
kdenetwork-kopete-libs-7:4.8.3-1.fc17.x86_64
kdenetwork-kopete-libs-7:4.8.5-1.fc17.i686
kdenetwork-kopete-libs-7:4.8.5-1.fc17.x86_64
libotr-devel-0:3.2.1-1.fc17.i686
libotr-devel-0:3.2.1-1.fc17.x86_64
mcabber-0:0.10.1-3.fc17.x86_64
pidgin-otr-0:3.2.1-1.fc17.x86_64
xchat-otr-0:0.3-5.fc17.x86_64
So 7 clients use it, so I am not going to assume all of these can fix
their code within a few days.
Do the old libotr and the new interoperate? Specifically, if one person
is running the current pidgin-otr/libotr, and another both new ones, can
they still talk?
Yes. The new one will just fall back to the old protocol when speaking
to old clients.
Just to clarify (and confirm I'm right), the above listed software
cannot just use libotr-4. They need to be fixed for libotr-4. However,
code fixed to use libotr-4, can talk to clients based on libotr-3 and
libotr-4.
Paul
_______________________________________________
OTR-dev mailing list
[email protected]
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
