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

Thibaut VARENE varenet at debian.org
Fri Aug 31 06:43:58 EDT 2012


On Fri, Aug 31, 2012 at 2:09 AM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Thu, Aug 30, 2012 at 06:33:48PM -0400, Paul Wouters wrote:
>> On Thu, 30 Aug 2012, Ian Goldberg wrote:
>>
>> >>So 7 clients use it, so I am not going to assume all of these can fix
>> >>their code within a few days.
>> >
>> >Indeed not.  They can continue to depend on the old version of libotr.
>> >(Your libotr3 package, if I understand it?  But does that mean you have
>> >to change all of the above packages to explicitly name libotr3?  If I
>> >understand the Debian/Ubuntu method correctly, the package name has been
>> >libotr2 all along, and all those other programs name libotr2 as their
>> >dependency.  The new package will be libotr5, and programs that update
>> >their use of libotr can then switch their dependency to libotr5.)
>>
>> 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 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.

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.

HTH

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



More information about the OTR-dev mailing list