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

[Daniel Atallah]

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
>>
>> <SNIP>
>>
>> Why was the ActiveTcl handling removed?
>>
>> Will these changes cause the Tcl plugin to now depend on a different Tcl flavor?
>
> OBS provides tcl implementation, so I've just switched the loader
> plugin from ActiveTcl to the implementation bundled with our other
> dependencies (pointed out below). This approach have advantage of
> simplicity: tcl plugins doesn't need any 3rd party software installed
> to work under win32.

Ah.  I missed that part.

That seems like a rather heavy addition to every download for
something that I suspect that nobody actually uses.

Our dependencies are getting quite a bit larger (Tcl/Tk don't
necessarily make a huge difference, but I think it's something to
think about - more below).

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

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

-D