Ian Goldberg <i...@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.
pgp0JDTxH1nBs.pgp
Description: PGP signature
_______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
