Bug#459244: asterisk: split-up proposal

[Faidon Liambotis]

jamhed wrote:
>> So I suggest you be more specific about what you want to move to
>> subpackages. Why would you want app_voicemail.so in a separate
>> package? What harm is it in this module lying around?
>>
>> One valid reason would be dependency on external libraries: odbc,
>> pgsql, netsnmp, radius, sqlite.  We have a separate asterisk-h323 . 
>>
> 
> What I've got so far:
<snip>
> So, it is way less than 164, only 48 so far.
48 packages is a bloat for no reason; think of all the overhead a
package has both on users and on mirrors and think of all the
maintainance burden.

> The general idea - every extra functionality goes to it own package,
> especially modules with it own config files, 
> so I will be able to select via aptitude what exactly my asterisk is
> intended for.
> 
> Just for example, I've never used mgcp, dundi, enum, jabber, snmp,
> smdi, odbc, sqlite, tds, chan_phone, chan_skinny, adsi, alarmreceiver,
> and definitly will never do. So what is the reason to keep loading
> unused modules into a production system ? Some of them spin out their
> own threads, some of them wants me to configure it.
You can always disable autoload and load only the modules that you want
to. You can leave them unconfigured or even remove the configuration
files. With the current infrastructure you can even provide a
configuration file package to not include these files *at all*.

> And I'd like to keep an asterisk installation lean and mean, with only
> functionality I've selected - so right now I'm forced to delete unused
> stuff, after each setup. 
/usr/lib/asterisk/modules is ~5M. It may not be "lean and mean" but it's
not exactly the opposite either.

>> One valid reason would be dependency on external libraries: odbc,
>> pgsql, netsnmp, radius, sqlite.  We have a separate asterisk-h323 . 
> 
> And yes, here is yet another reason to separate, at least all stuff
> depended on externals, like pgsql, mysql, etc.
That is an actual reason.
I've thought about it myself, splitting some modules to different
packages to minimize the dependency chain.

I'm leaving this open, because it's a valid request -for that last
reason- that needs a little bit more though.

Don't expect us to split asterisk to 48 packages though, there's no way
this is going to happen ever.

Thanks,
Faidon