[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 <i...@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. _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
