On Fri, Aug 31, 2012 at 2:14 PM, Ian Goldberg <[email protected]> wrote: > On Fri, Aug 31, 2012 at 12:43:58PM +0200, Thibaut VARENE wrote: >> >> Yes, I will send patches to the maintainers of these to change their >> >> Require: libotr to Require: libotr < 4. The libotr3 package will supply >> >> libotr < 4, while the libotr package will supply libotr >= 4. >> > >> > Since they're using the libotr 3 API, shouldn't they require libotr == >> > 3? And the new libotr package will supply libotr == 4, and the new >> > pidgin-otr package will require libotr == 4? (As opposed to >= 4?) >> >> I think all that is relatively pointless. Ian: libotr2 will no longer >> be actively maintained/developed when libotr5 is released, right? > > If there's a security release needed, I'll consider pushing out a 3.x > security update for at least a little while, but I haven't set a firm > timeline policy or anything like that.
OK. That confirms what I was expecting. >> If so, I plan to move on with the current state of things in Debian: >> libotr 4.0.0 (source package providing libotr5, -dev and -bin) will >> *replace* libotr 3.2.1 (source package providing libotr2, -dev and >> -bin) at which point packages that still require libotr2 will simply >> break, and their respective maintainers will have to take action. > > Isn't that impolite to those maintainers? Or will you give them a > heads-up in advance? The notion of "politeness" in FOSS makes me chuckle ;-) The heads up they have is 1) (for upstream) your release announcement: after all, they're writing code that uses your library, so they should know what they have to do already; and 2) (as far as Debian maintainers are concerned), the upload of the new version of the library to 'experimental', which has already happened and is pending validation. It appears people are already well aware of the upcoming change too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685664 Again, we're not breaking libc here. From what I read, I don't think the new version of libotr will impose a complete rewrite of dependent software, right? ;-P >> I don't think libotr has that many dependencies nor is that a critical >> package that it warrants the maintaining of 2 different versions over >> the lifetime of major linux and BSD distributions just for the sake of >> easing dependencies' transitions. At least for Debian, that's how >> things will be done. > > Sounds reasonable. > > I plan to build the test releases of 4.0.0 today, including the patch to > fix the exit() issue, and an extremely minor "remove whitespace at the > ends of a handful of lines" source cleanup patch. OK. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
