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. > 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? > 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. Thanks, - Ian _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
