Re: [Gaim-devel] relaytool

[Robert M. <rob...@de...>]

This scares me a lot. It adds a huge degree of complexity to the fairly 
common case of people just grabbing source and building a binary, and to 
  the also very common case of distributors (ie not us) creating 
binaries for the users. In these cases, less strict binary dependencies 
are bad, because the user will just have the wrong thing installed, and 
it won't do what they expect, so we'll get more complaints. If it caught 
the fact that $foo isn't installed, or isn't a sufficient version, when 
they ran configure or tried to install the package, this problem 
wouldn't occur.

The potential for further confusion is quite heinous - it would totally 
break Debian's shlibdebs mechanism. Its not possible to automatically 
determine dependencies for libraries which are dlopened - the current 
situation of having plugins which are actually linked with eg perl, nss, 
tcl, etc, is good because these dependencies are correctly found, and in 
some cases made not mandatory by me, and if you don't have the library, 
Gaim will not be able to dlopen the plugin.

The prefix-finding stuff was fairly self-contained, but this looks like 
a far greater deviation from the norm of just compiling and linking 
stuff like the rest of the world. It seems like too disruptive a change 
to the common case, especially if it's not strictly necessary to work 
with autopackage.

So no... not keen on this. I was aware you could do it in theory, and 
had suggested it in jest on a few occasions, but had never actually seen 
an implementation. Something like "heh" comes to mind... :)

Regards,
Rob

Tim Ringenbach wrote:
> I'd like to get some opinions on relaytool, and whether or not we'd be 
> interested in using it. It's a shell script that you can read at 
> http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/autopackage/apbuild/relaytool 
> and is written and maintained by the autopackage guys.
> 
> Basicly what relay tool lets you do is dlopen a library without 
> significantly modifying your code that uses it. It builds a stub object 
> that uses dlopen for you, so the symbols are always available to Gaim so 
> it can run with or without it.
> 
> What you end up with is a bunch of if's after all your #ifdef's. This 
> shouldn't make the code any uglier or more complex really, since the 
> if's are a line after the #ifdef's and do the same thing.
> 
> I suspect if people have objections to this, it will be with the low 
> level implemention, which I admit I don't really understand. The script 
> only works on certain platforms and needs asm code for each arch it 
> supports, but works as if it weren't there on platforms it doesn't 
> support (which looks like right now is anything besides x86 and ppc).
> 
> The benefit using relaytool gains us would be binary packages would have 
> less strick dependencies, and upgrading the dependencies wouldn't 
> require a gaim recompile to gain whatever benefit the new version provides.
> 
> In more concrete terms, you could build against gtkspell, but not 
> require it. Package formats that support "Recommends" can recommend it, 
> and if its there you get spell checking, if it's not there you don't. We 
> could go all out and relaytoolize nearly everything, libao and 
> audiofile, silc, tcl, perl, the ssl libs, etc. (Although nothing focuses 
> us to, it can be used as little or much as you want.)
> 
> It can also be used for stuff like gtk. So packages could depend on Gtk 
> 2.0, but if gtk 2.4 is installed they get the file selector and all the 
> other gtk 2.4 features.
> 
> 
> One pitfall, though, is that package builders need to have optional 
> packages installed, and newer versions of e.g. gtk. This is the exact 
> opposite of how it normally works, where they need the oldest version. 
> If you relaytool gaim's use of gtkspell, but compile gaim without 
> gtkspell, then gaim never uses gtkspell, all the gtkspell code including 
> the runtime checks for its existence are #ifdef'd out.
> 
> Obviously, this is most useful for something like autopackage, which 
> tries to make distro neutral binaries and have one binary work equally 
> well on rh8 and fc3, etc. But I think it's generally useful for all our 
> binaries.
> 
> 
> So I guess there's two main questions that need answered:
> 1. Does it provide enough benefit to be worth bothing with?
> 2. Is the implemention good enough?
> 
> Anyway let me know what you think. And I realize some people are out of 
> town, and I'll wait until they return before trying to draw any final 
> conclusions.
> 
> --Tim