The answer to question 1 is it builds all modules, including ones you don't necessarily want, so you can install just the modules you want on your production machines to save disk space, etc.

This works best if you run your own local APT repository, sign the built packages and upload them there. There's a few tools around for doing that (reprepro mini-dinstall etc). Add it on the servers to sources.list and you can easily distribute it to your production servers with the bonus that all the servers are running the same build as you tested with.

There's an official one too but it's rather out of date (http://files-sync.freeswitch.org/repo/deb/debian/)

-Steve



On 12 March 2013 13:04, Andrew Cassidy <andrew@cassidywebservices.co.uk> wrote:
I've been using that build script in chroots for the matrix of [i368,amd64] x [sid,squeeze,wheezy]

The answer to question 1 is it builds all modules, including ones you don't necessarily want, so you can install just the modules you want on your production machines to save disk space, etc.

On 12 March 2013 12:44, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> wrote:
Hey,

So today I went to go and create a Debian package for FreeSWITCH using the existing packaging structure;


The first problem is that neither the helper or the debian/ dir have been configured for compatibility with pbuilder, which makes it untidy/non-sane to place this onto an automated production build system (it also impacts security slightly due to untrusted external code being ran outside of a chroot - but that's possibly an entirely different debate).

The second problem is that the build resulted in nearly 100 different *.deb files This also poses somewhat of an annoyance in automated deployment environments, for example saltstack, where the configuration would have to list each individual FreeSWITCH module. It also feels very untidy. I understand that certain packages (such as libfreeswitch, libfreeswitch-dev, freeswitch-server etc) should be separated. But having a package for each module, the only use I could think of for this, would be if the Debian package compiles absolutely every module possible, and is then linked dynamically, rather than compiled static. This means enabling/disabling modules would be a matter of simply adding/removing a package. However I'm not entirely convinced if this is what it is doing.. when compiling absolutely every package possible, FreeSWITCH will usually fail to compile, due to collision etc.

So I have a couple of questions;

1) Why are the modules separated into individual files? 

2) Are there any reasons to not be using pbuilder?

I have also CC'd Travis Cross who appears to a major contributor on the Debian packaging code.

Thanks

Cal

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org




--
Andrew Cassidy BSc (Hons) MBCS SSCA
Managing Director

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org