[Asterisk-Dev] New app_groupcount.so in SVN-trunk-r7413 broken

[Steven Critchfield]

On Thu, 2005-12-15 at 13:59 -0600, Kevin P. Fleming wrote:
> Chris Parker wrote:
> 
> > Your 'addon' modules would  be compiled against a specific version of  
> > asterisk.
> > If you're upgrading asterisk, recompile the modules against the new  
> > version.
> 
> So we have to rev the version number any time any part of the API 
> changes, or any time the content of modules changes such that old 
> modules would conflict with new ones, even if there are no API changes. 
> That would be extremely difficult to manage properly, and would result 
> in hundreds of excess 'old' modules left on people's systems.

Not to mention maintaining a list of essentially blacklisted modules
because their version isn't up to current.

> > Hmmm, then you nuke something that may or may not be easily replaced,  
> > ala g729, etc.
> > if another copy isn't available elsewhere on the system.  Unless I'm  
> > misreading
> > your statement.
> 
> When (if) this change happens, there will be plenty of warning, and the 
> first version of it will only move the excess modules out of the way, 
> not delete them. In fact, we may just do it that way permanently, with a 
> message telling you that it happened and where the modules got moved to.

The method of moving them to the side would be preferable. In fact maybe
a method(possibly already supported) to load from a non-core asterisk
directory. So out of tree modules could be configured to load from out
of tree directories. This solves the nastyness of deleting modules that
you don't want deleted.

For instance the annoyance of the NVidia libraries being wiped out when
I make modules_install under the linux kernel tree so my next reboot
leaves me without X due to missing drivers. In my case, the API didn't
change, but the assumption about nuke the directory and put all the
modules back in can be highly annoying.


-- 
Steven Critchfield <critch at basesys.com>