freepbx-modules

[Tzafrir Cohen]

Jsut to get the facts straight, as the fbx-modules script seems to cause
some confusion,

On Wed, Oct 29, 2008 at 11:20:52AM +0000, Daniel Watkins wrote:
> Hello all,
> 
> As some of you may be aware, FreePBX is almost entirely modular.  As a
> result, to get any sort of usability from the freepbx package, some
> modules need to be installed.

Specifically, upstream updates modules separately in separate tarballs.

> 
> Currently in the pkg-voip repository, there is a 'freepbx-modules'
> package, which contains a script which downloads whatever the latest
> modules from upstream are, where they are distributed and released
> independently of one another, and generates debian/control sections,
> preinst and postinst scripts and a list of installable files for each of
> them.  A separate binary package for each module is created.

This is how it was originally layed.

Multiple binary packages allow the user to easily control the installed
modules. But this is laos mostly possible through enable / disable in
the web interface . Very few modules (if at all) have external
dependencies that wouldjustify putting them in a separate subpackage to
avoid pulling the extra dependency.

Thus I later merged all the binary packages to a single one. The
fpx-modules script still preserves the old layout. But I just dumped its
changes to debian/control last time I needed to use it.

> 
> I don't particularly like this, as the script essentially reimplements a
> package management system, with much less testing than apt actually has.
> Furthermore, if any of the modules (there are currently 54) is released,
> then all of the packages have to be updated.
> 
> I'm not really sure of the best way to solve this, but I'm fairly sure
> what exists at the moment is not it.  To my mind, there are a number of
> options available:
>       * continue using the existing method, with a single source package
>         and many binary packages

This is not the current situation. And I don't want to go back there.

>       * have a single source package and a single binary package

This is the current situation. Sub optimal, but possible.

>       * package each upstream module as a separate source package

Is this practical?

>       * package a few 'core' modules as a single source package and
>         package the rest of the modules as separate source packages

Or a variant of that: 

        * Package the core, and re-reenable the web interface to manage
	  modules. Err... and hope for the best to handle upgrades :-(

>       * continue using a single source package generating many binary
>         packages, but remove some of the magic that makes it happen
> 
> I'm not really sure which of these is best, or even if this is an
> exhaustive list.  Any input would be appreciated.

-- 
               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