[OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

[Ian Goldberg]

[Rearranging...]
On Thu, Aug 30, 2012 at 01:55:16PM -0400, Greg Troxel wrote:
> (Sorry if I sound cranky; I'm not really trying to complain about how
> things are, just to point out that the questions I'm asking are the key
> questions one needs to have answered to decide what to do, and that they
> are missing from the pre-release announcement.)

Oh, they're good questions.  I guess my lack of experience with pkgsrc
(and *bsd in general) is showing. :-p
> 
> Ian Goldberg <ian at cypherpunks.ca> writes:
> 
> > On Mon, Aug 27, 2012 at 08:22:17PM -0400, Greg Troxel wrote:
> >> ok, but do the current releases of all those build against libotr-4?  If
> >> so, there is no issue in pkgsrc (even if they were all packaged, which
> >> they're not).  If not, then there are bigger problems.
> >
> > No, this is a major version number increment, which means that the API
> > and ABI have changed from the application's point of view.  That's why
> 
> That doesn't all logically follow (beyond ABI).  It seems you mean
> "major version number increment, without backwards-compatible API
> support" (which can be coped with), but that was not at all clear
> earlier.

Fair enough.  Yes, libotr follows the "bump major when ABI changes
incompatible; bump minor when ABI changes in a backwards-compatible way;
bump sub when implementation, but not ABI, changes" convention.

> > debian/ubuntu/etc. add the so major number to the package name:
> > xchat-otr and friends can still depend on libotr2 for a while, until
> > they update their code, while the new pidgin-otr can depend on libotr5.
> > Surely pkgsrc supports some equivalent notion?
> 
> Yes -  when upstream packages don't provide API back-compatibility, then
> there are packages with the version number in the name (not a shlib
> number).  Or one without, that's "normal", and one or more with.  For
> unstable upstreams, there is typically always a version.

OK.

> So then:
> 
>   are the set of files installed by these two versions distinct, so that
>   they can not conflict, or is a system limited to at most one?

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.

> 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.

   - Ian

PS: I've decided that Tuesday Sep 4 will be the release day, so that
it's not buried in the long weekend.