/pidgin/main: 71533f0d5dc0: win32: switch to OBS, update and pus...

[Daniel Atallah]

On Mon, Apr 8, 2013 at 7:33 AM, Tomasz Wasilczyk <tomkiewi at gmail.com> wrote:
> I missed the fact, that Pidgin installer stores installation directory
> path in "HKLM\SOFTWARE\Pidgin\[default]" and dependency bundle is
> installed always under it. So, such function could first check, if
> such directory exists, and (as a fallback) would use a path relative
> to current installation directory (these two would differ in case,
> when we run not yet "installed" devel version). In both cases, we use
> full patch to dll.

The installer actually may or may not write to the HKLM registry
depending on the permissions of the user who ran the installation.

I think I'd rather keep it simple and not use the registry at all -
just make it always work relative to the pidgin dll.

This will eliminate a bunch of issues with unexpected behavior when
someone tries to run a standalone or devel version of pidgin and
starts picking up things out of the installed version.
`make install` (or perhaps some other target) should ideally set up
the development version so it can run completely in-tree


>> I have some apprehensions about a monolithic runtime dependency zip.
>>
>> The idea with the current installer model is that the "online"
>> installer would only contain things that change relatively frequently
>> and updates wouldn't need to download the gtk bundle because they
>> would already have everything in it.
>>
>> I realize that the current situation with the gtk bundle makes some
>> relatively arbitrary distinctions, but that was the idea.
>>
>> If the change is made so that all dependencies are separate, I think
>> that also means that they will likely change more frequently and makes
>> it less useful to have a "lighter weight" installer used for upgrades
>> like we have today.
>
> So far, Pidgin used gtk release from gnome.org, which used not to be
> updated frequently. The side effect was, that gtk bundle had to be
> updated once per few Pidgin releases. But it also resulted with
> shipping Pidgin with ancient versions of gtk/glib.
>
> But now, when we have easy access to more recent gtk/glib releases via
> OBS, they will be not less frequently updated (or, at least,
> possibility of update) than other dependencies, shipped directly with
> Pidgin binary.

That's actually not really the reason (or at least not the only
reason) that we ship old versions of some of those dependencies.
The main reason we still run GTK+ 2.16.6 is that newer versions are
broken in various ways.
Even the latest GTK2 release (2.24.17) has some showstopper issues
(e.g. https://bugzilla.gnome.org/show_bug.cgi?id=671538).

> According to Pidgin release cycle, I see two cases, depending on how
> long it took since previous release:
> - short period (few days, weeks): deps package won't be updated, user
> gets only our binary without half of dependencies
> - long period (half a year, few months): most of dependencies will get
> its updates, both in current gtk bundle and these shipped with Pidgin
> installer, so it would be anyway decent to update the bundle

This is probably a decent evaluation, although I think historically
it's actually been pretty rare that we make changes to dependencies.

> I also see another solution, which actually make a real distinction
> between rarely and frequently updated dependencies: updates would be
> divided into two genres:
> - big: most of dependencies gets its updates and new bundle is shipped
> (the simple one)
> - patch: one or two dependencies have to be fixed against some
> security issue - they will be shipped directly with Pidgin (and loaded
> with higher priority than the one from deps-bundle) and will be
> included in next "big" deps update
> I can implement the logic for this.

This is an interesting idea.

> And another solution: shipping two dependency bundles - one for gtk
> and one for others. But, in my opinion, both will get equally frequent
> updates (as I said above). I can implement it also.

Taking it a step further, would we think about splitting out the
dependencies into package-level granular groupings and make the
"online" installer evaluate and update each package independently as
necessary.  This may be a lot of work though.

To be honest, I don't foresee us changing the dependencies all that
much more frequently than we do now.  Generally, I'd like to avoid
changing stuff unless there's a compelling reason to do so (security
fix, fix to specific bugs that impact us, major functionality
addition).

> Apart from the problem above, I have few questions about some of
> dependencies, I didn't migrated to OBS:
> - mozilla nss+nspr: do we apply any security patches for it, or just
> build it because there were no good releases for win32? In the second
> case, I assume it can be safely switched to OBS release

We don't apply any patches to NSS/NSPR (apart from those necessary to
make it build) - there's a wiki page for how this is currently built:
https://developer.pidgin.im/wiki/BuildingWinNSS

I noticed that libxml2 was downgraded (I know you specifically said it
was temporary, but it's an example) to a version with known
vulnerabilities.

The biggest concern for this (and other things) is that we need to be
able to get security fixes in a timely manner - that's part of the
reason I want to get a scripted "build everything from scratch" setup.

> - cyrus sasl, silc toolkit: where does it comes from? how is it built
> (there is no info about that)? it differs from the upstream release

I built both of these manually.

CyrusSASL isn't patched except that we also ship their saslGSSAPI
module built against MIT Kerberos for Windows.  I suspect that the OBS
CyrusSASL wouldn't include this module, which is necessary for
Single-Sign On capabilities.
I built the module a number of years ago and have continued to ship
the old binary as we've upgraded Cyrus.

SILC is built from upstream without any patching.

> - perl_5-10-0: what's that? where does it comes from?

It's the development headers for Perl.  It was extracted from the
ActivePerl runtime.
Similar to the situation with the Tcl building, the perl plugin loader
is built against Perl but we don't ship a Perl runtime; the user needs
to bring theirs to make it work.

> - pidgin-inst-deps - I see no documentation about it

pidgin-inst-deps  contains a couple "external" things:
 * There's a NSIS plugin that I wrote to do a SHA1sum calculation on
files it downloads so that they can be compared to the expected values
- the source is in the zip file.
 * The other thing is the crash-reporting library (exchndl.dll).  The
source is here: https://hg.pidgin.im/util/drmingw/.

I realized that there are a couple other issues with some of the
dependency changes - I'll reply to the commit email with some in-line
comments about them to avoid having this email get too off-topic.

-D