[asterisk-dev] How to split Asterisk packages

[Tzafrir Cohen]

On Thu, Dec 30, 2010 at 08:23:12PM -0800, Jonathan Thurman wrote:
> On Thu, Dec 30, 2010 at 7:05 PM, Alan Jones <skyphyr at gmail.com> wrote:
> > Anyway - the headers would go in a -devel package, the pdf in a -doc package,
> > sounds would be split by language, codec, and I guess core and extra (though
> > how do I tell them apart once it's in the final directory structure?).
> 
> I am not familiar with the build setup for Pardus, but for RPM based
> builds I create different configuration files and builds for the sound
> packages.  That way you know that the sound files belong in extras
> because your build tree only has the sounds-extra for that language in
> it.
> 
> > Also are the
> > empty .asterisk*sounds* files required? Any others I should delete?
> 
> Looking at the way Digium packages sound files, the .asterisk-*sounds*
> files are included.  Any README / CHANGES should be put into the docs
> directory IMHO.
> 
> > Then when it gets to modules etc I get extra unsure what should be done. Is it
> > worth spitting these apart?
> 
> Personally, I split things out into a lot of packages for many
> reasons.  Save disk space, less to download, less to patch, less to
> break (unless you don't get dependencies right...), and less loaded at
> run time (if you have autoload = yes).  Disk space might seem silly,
> but if you add for example ODBC support, then you need to make sure
> that all of the libraries are installed and updated for ODBC as well
> as the module file for Asterisk.

OTOH, it's easier to forget to install some package. The Digium package
split Asterisk to way too many packages, IMHO. For another perspective,
look at how it is packaged in varius distributions.

> 
> An ODBC sub-package would contain all of the odbc modules (res_odbc,
> res_config_odbc, cdr_odbc, cel_odbc, etc), LDAP is another one that
> would be the done the same.

An external dependency is indeed a valid reason. Though if you don't use
Asterisk for a specific application (and thus have another package to
pull all the right sub-packages) the user might not notice the need to
install asterisk-odbc to get ODBC support in <whatever>. BTW: this still
will not do for ODBC storage for voicemail. That's even more tricky.

> 
> 
> > i.e. I have the dahi kernel modules and dahdi-tools
> > in other packages as their source is separate. Should the dahdi dependent
> > asterisk config and modules be split out? Then there's all the other ones and
> > where it starts/ends becomes especially unclear to me.
> 
> The configurations for the modules should be kept with the package
> that contains the module.  No sense in having a configuration file for
> chan_mgcp if you are never going to use it.  

I prefer a single package with all the configuration (that comes from
the main package). That makes it easier to replace and worry about.

> I also would encourage
> you to put the sample configurations it the Documentation section for
> the package.  Having them installed into /etc/asterisk (or where ever)
> has proven to be a little dangerous to me.  The only exception that I
> make to that would be asterisk.conf, as it is pretty safe if it gets
> replaced on accident (but you don't want an extensions.conf file to
> change on an update by mistake!)

They naturally should not just get replaced. Various package managers
have some smarter ways of handling this.

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