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

[Tomasz Wasilczyk]

2013/4/8 Daniel Atallah <datallah at pidgin.im>:
> On Sun, Apr 7, 2013 at 7:54 PM, Tomasz Wasilczyk <tomkiewi at gmail.com> wrote:
>> 2013/4/8 Daniel Atallah <datallah at pidgin.im>:
>>> On Sun, Apr 7, 2013 at 4:22 PM, Tomasz Wasilczyk
>>> <tomkiewicz at cpw.pidgin.im> wrote:
>>>> Changeset: 71533f0d5dc06a5a5ecfc7dee1713a83e184534b
>>>> Author:  Tomasz Wasilczyk <tomkiewicz at cpw.pidgin.im>
>>>> Date:    2013-04-07 22:22 +0200
>>>> Branch:  default
>>>> URL: https://hg.pidgin.im/pidgin/main/rev/71533f0d5dc0
>>>>
>>>> Description:
>>>>
>>>> win32: switch to OBS, update and push to runtime-deps package - libenchant, gtkspell, meanwhile, tcl
>>>
>>>> -       tmp = g_build_filename(wpurple_install_dir(), "spellcheck", GTKSPELL_DLL, NULL);
>>>>         /* Suppress error popups */
>>>> -       wpidginspell_new_attach_proxy = (void*) wpurple_find_and_loadproc(tmp, "gtkspell_new_attach" );
>>>> +       wpidginspell_new_attach_proxy = (void*) wpurple_find_and_loadproc(GTKSPELL_DLL, "gtkspell_new_attach" );
>>>
>>> The full path for this and various other dynamically loaded things is
>>> intentional and necessary to protect against a particular class of
>>> attacks.
>>> The same applies to the Tcl initialization above.
>>
>> I've been thinking of it. Anyway, we don't have a path to directory
>> where our bundle with dependencies was installed. I can figure out a
>> way to tell nsis to store it at "HKLM\SOFTWARE\Pidgin" (we already
>> have version number stored here). I could then implement a function
>> called wpurple_loadproc_trusted(dllname, "funcname"), which would
>> search for dll only in this directory. Do you think it's a good
>> solution?
>
> I don't think we need to use the registry.  We should be able to load
> stuff with paths relative relative to the pidgin dll (that's what the
> gtkspell code used to do).

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.

> 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.

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

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.

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.

> I'm not sure what the solution is, but it's something to think about.

Definitely, yes. We have a lot of time till 3.0.0 release, and these
binaries can pretty easily be included back with main installer.


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
- 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
- perl_5-10-0: what's that? where does it comes from?
- pidgin-inst-deps - I see no documentation about it

Tomek