El vie, 26-11-2004 a las 09:41 +0000, Robert McQueen escribi=C3=B3:
> This scares me a lot. It adds a huge degree of complexity to the fairly=20
> common case of people just grabbing source and building a binary, and to=20
> the also very common case of distributors (ie not us) creating=20
> binaries for the users.
Currently, apart from the code complexity, I do not see in which way it
adds complexity at all.
> In these cases, less strict binary dependencies=20
> are bad, because the user will just have the wrong thing installed, and=20
> it won't do what they expect, so we'll get more complaints. If it caught=20
> the fact that $foo isn't installed, or isn't a sufficient version, when=20
> they ran configure or tried to install the package, this problem=20
> wouldn't occur.
Really, really few people build from source. This relay tool has the
potential to increase the user base, since new Gaim users would not need
to install all of Gaims dependencies.
> The potential for further confusion is quite heinous - it would totally=20
> break Debian's shlibdebs mechanism. Its not possible to automatically=20
> determine dependencies for libraries which are dlopened - the current=20
> situation of having plugins which are actually linked with eg perl, nss,=20
> tcl, etc, is good because these dependencies are correctly found, and in=20
> some cases made not mandatory by me, and if you don't have the library,=20
> Gaim will not be able to dlopen the plugin.
> The prefix-finding stuff was fairly self-contained, but this looks like=20
> a far greater deviation from the norm of just compiling and linking=20
> stuff like the rest of the world. It seems like too disruptive a change=20
> to the common case, especially if it's not strictly necessary to work=20
> with autopackage.
> So no... not keen on this. I was aware you could do it in theory, and=20
> had suggested it in jest on a few occasions, but had never actually seen=20
> an implementation. Something like "heh" comes to mind... :)
> Tim Ringenbach wrote:
> > I'd like to get some opinions on relaytool, and whether or not we'd be=20
> > interested in using it. It's a shell script that you can read at=20
> > http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/autopackage/apbuild/relayt=
> > and is written and maintained by the autopackage guys.
> > Basicly what relay tool lets you do is dlopen a library without=20
> > 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 s=
> > it can run with or without it.
> > What you end up with is a bunch of if's after all your #ifdef's. This=20
> > shouldn't make the code any uglier or more complex really, since the=20
> > 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=20
> > 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=20
> > supports, but works as if it weren't there on platforms it doesn't=20
> > support (which looks like right now is anything besides x86 and ppc).
> > The benefit using relaytool gains us would be binary packages would hav=
> > less strick dependencies, and upgrading the dependencies wouldn't=20
> > require a gaim recompile to gain whatever benefit the new version provi=
> > In more concrete terms, you could build against gtkspell, but not=20
> > 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. W=
> > could go all out and relaytoolize nearly everything, libao and=20
> > audiofile, silc, tcl, perl, the ssl libs, etc. (Although nothing focuse=
> > 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=20
> > packages installed, and newer versions of e.g. gtk. This is the exact=20
> > opposite of how it normally works, where they need the oldest version.=20
> > If you relaytool gaim's use of gtkspell, but compile gaim without=20
> > gtkspell, then gaim never uses gtkspell, all the gtkspell code includin=
> > the runtime checks for its existence are #ifdef'd out.
> > Obviously, this is most useful for something like autopackage, which=20
> > tries to make distro neutral binaries and have one binary work equally=20
> > 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=20
> > conclusions.
> > --Tim
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.=20
> Gaim-devel mailing list
Manuel Amador <rudd-o@...>