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

Greg Troxel gdt at ir.bbn.com
Thu Aug 30 16:36:23 EDT 2012


Ian Goldberg <ian at cypherpunks.ca> writes:

> Oh, they're good questions.  I guess my lack of experience with pkgsrc
> (and *bsd in general) is showing. :-p

Perhaps, but I don't think my questions are bsd-specific - it's more
about any system that has to manage lots of software maintained by third
parties and get depdendencies right.  The issues with pkgsrc and e.g
ubuntu are really the same, and the approaches seem to be broadly
similar, with just details different.

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

Glad to hear it - and that's a pretty hard rule out there for shlib
versioning.

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

The notion of runtime and dev packages is Linux-specific.  In pkgsrc,
the emphasis is on building a single package from source, because there
are such a large number of operating systems, os versions, and binary
architectures (many of which lack the critical mass to have people
building binaries and putting them up for download, which really only
happens for the most popular combinations).  So building split binary
packages with some parts of a package and not other parts isn't really
done much, unless there's a really good reason.   Avoiding installing
header files to save disk space is usually not considered a good reason
:-), but avoiding the utility program that drags in qt is.

But that answers my question - some filenames overlap, so the packages
have to conflict (if we have both at once).

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

I didn't quite say this, but it would have been nice if the new package
supported the old API (I say that not caring much about ABI).  As
libraries become more and more widely used, that kind of stability
becomes more important.  Conversely, I think there's a bias against
depending on things that don't have that property, because it requires
synchronous updates, or to have earlier releases of depending packages
that can autoconf/switch.  But I realize time is limited and otr has few
depending packages (even if it's 10, that's few).

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

Glad to hear it - that's obviously the critical upgrade interoperability
issue, since it can't be worked around locally in any sane manner.

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

Thanks for the warning; I may be able to have an update for pkgsrc ready
to go.  Thanks for listening - I'm done ranting for now and have enough
info to prepare the update.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20120830/3646d8ef/attachment.pgp>


More information about the OTR-dev mailing list