asterisk-addons

[Tzafrir Cohen]

On Fri, Jan 06, 2006 at 10:22:45PM +0100, Jose Carlos Garcia Sogo wrote:
> On Fri, Jan 06, 2006 at 10:15:28PM +0200, Tzafrir Cohen wrote:

> > Basically I think that those modules need to depend on "asterisk 
> > interface" of a specific version, and the version number of that 
> > interface should be bumped whenever a change in Asterisk breaks modules. 
> > This is much like the kernel version number.
> > 
> > This applies to any other out-of-tree module: the spandsp modules (fax
> > and dtmftotext), chan_oh323, and probably some others.
> 
>   Yes, the problem is defining that interface. I mean, asterisk upstream
>   should be the one defining that, and changing it only when needed,
>   clearly stating that. If not, we will have to check every module
>   depending on asterisk to see if it needs a recompile or not, or wait
>   for some user to report us a bug.

If you ask the developers, they'll probably answer "rebuild all modules
on every asterisk rebuild". But we do want to provide some better
guarantees.  In the case of the Linux kernel's interface to modules you
have a situation that is basically the same.

I wonder if there is any way of automating the interface test. If this
would have been a simple matter of static loading, 'ldd -r' would have
been good enough. But here ldd -r will complain of many missing
functions that should be provided by Asterisk.

(This won't expose a case where thesame function exists, but is called
differently on the newer version)

BTW: did you notice that Digium provides a single codec_g729a.so version
for all versions of asterisk? They were probably a bit careful with the
functions they used. But still, I don't recall them striking out a
certain change because it broke their binary codec_g729a.so .

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen at xorcom.com  http://www.xorcom.com