[OTR-dev] libotr and pidgin-otr 3.1.0-preview2 available

[Greg Troxel]

Ian Goldberg <ian at cypherpunks.ca> writes:

> On Fri, Jul 27, 2007 at 07:51:25PM -0400, Greg Troxel wrote:
>> I don't mean to rant, but I'm trying to package pidgin-otr and having a
>> harder time than seems necessary.  I'm experienced enough at packaging
>> that I suspect others are too.
>> 
>> 1) at http://www.cypherpunks.ca/otr/ it says that there is
>> 
>>    OTR plugin for Pidgin (formerly known as gaim)
>> 
>> and the file is http://www.cypherpunks.ca/otr/gaim-otr-3.0.0.tar.gz But
>> this file is a plugin for gaim (1.5), not for pidgin (which to me
>> implies 2.0).  The headline should indicate clearly that this is for
>> gaim 1.5.X.
>
> We're just waiting for the final release version of 3.1.0 to be ready,
> which looks like Aug 1 plus or minus a day or two.  All that's left is
> some tidying of some of the documentation.  At that point, the old
> versions will come off the website.

It's fine that 3.1.0 isn't out, but my point that the current gaim 1.5
plugin is mislabeled as pidgin remains.  Plus, I think that the gaim 1.5
plugins should remain available until it's reasonable to tell people
that they're being completely ridiculous to be running 1.5.  Given that
2.0 has been out only a short time, I don't think that's happened yet.

>> 3) It seems that pidgin has been out for a while, so it never occured to
>> me that there is no released otr plugin based on the beta one that's
>> been around for ever.  If this is really the case the top-level web page
>> should explain it - I expected to find pidgin-otr-3.0.0 and haven't been
>> able to.
>
> As above, pidgin-otr-3.1.0 will appear next week.

OK, but please keep in mind that visitors to the web site are not aware
of your announced-on-the-list plans, and that the web site should
clearly and correctly explain the status of the world at all times.  A
simple "These files are for gaim 1.5.  Support for pidgin 2.0 has not
been released and is expected soon." would do wonders.

>> 4) I found Ian's message about preview2, and downloaded it.  It would be
>> good to use 3.1.0a2 to follow normal conventions for prerelease
>> software, and to have the directory name match the version name, so that
>> packaging software that assumes it will match won't need adjusting.
>> Right now 3.1.0-preview2 unpacks into 3.1.0.
>
> I did that sort of on purpose; -preview2 isn't meant to be an alpha
> release.  It's meant to be something which structurally will be
> identical to the upcoming release.  That way, packagers can see if
> there's something broken that I'd need to fix before the 3.1.0 actual
> release.

My point is that it isn't structurally identical, because releases
unpack into directories that match the file name, and this doesn't.  But
I suspect that you did 'make dist', and then just renamed it.  I realize
that not renaming it is no good either...

>> 5) pidgin-otr-3.1.0 seems to need libotr-3.1.0.  While this might really
>> be necessary, it would be really nice to decouple gui issues from core
>> protocol issues, and to only depend on released libraries - even for
>> unreleased plugins.  It's awkward to test pidgin-otr-3.1.0 while not
>> breaking gaim-otr-3.0.0 on the same system.  (I'd hope that 3.1.0 is API
>> and ABI compatible, but you'll forgive me for not being confident in
>> this given all of the above.)
>
> Indeed, installing libotr-3.1.0 will not break an existing
> gaim-otr-3.0.0.  pidgin-otr-3.1.0 naturally requires libotr-3.1.0, since
> it uses the library's new features.

So I guess my point is that it would have been nice to have
pidgin-otr-3.0.0 that worked with the old libotr.  Because of this it
was harder to test.

> So when pidgin-otr-3.1.0 and libotr-3.1.0 get released for real next
> week, they'll build cleanly on NetBSD?  That's good to know.

Yes, except for the shlib version issue, which I'll follow up separately
on.  I have packages ready to commit to pkgsrc once I remove previewN,
update checksums, and remove the line to make it build in a directory
other than the one implied by the distfile.