Another big problem you're likely to get is that pbuilder expects debian/changelog to be kept updated. That's not practical for the number of commits Git gets, hence generating a new entry from <span style="background-color:rgb(249,249,249);line-height:1.1em">next-release.txt + the date.</span><div>
<span style="line-height:14.296875px"><br></span></div><div><span style="line-height:14.296875px">IMO the release tarballs should get the debian/changelog updated for version releases - there is a Jira on that: <a href="http://jira.freeswitch.org/browse/FS-4778" target="_blank">http://jira.freeswitch.org/browse/FS-4778</a></span><br>
<div><br></div><div>-Steve</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On 12 March 2013 12:59, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.</blockquote>
<div><br></div></div><div>That's exactly what it's trying to do. It attempts to build every package, allowing you to install only what you need.</div><div><br></div><div>Modules are created as .so packages that are loaded dynamically when FreeSWICH loads the module. They're all linked against the shared libfreeswitch library which provides the core API. Modules such as mod_sofia link statically against that library (so libsofia is in mod_sofia.so not freeswitch itself). Any system libraries used may be linked by the module dynamically (libjpeg by mod_spandsp etc).</div>
<div><br></div><div>If you want to limit the modules built create a debian/modules.conf file and list them in there (same format as modules.conf). The debian/bootstrap.sh script reads that file and generates the packaging from that.</div>
<div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2) Are there any reasons to not be using pbuilder?</blockquote>
<div><br></div></div><div>The debian/bootstrap.sh is probably the primary reason it doesn't play well with pbuilder - debian tools will often assume the packaging is usable without any bootstrap step.</div><div><br></div>
<div>
The bootstrap is necessary for two reasons: 1) it allows the module build list to be customised by the builder 2) it makes that list manageable by automating the package generation.</div><div><br></div><div><br></div><div>
-Steve</div><div><br></div><div><br></div><br><div class="gmail_quote"><div><div>On 12 March 2013 12:44, Cal Leeming [Simplicity Media Ltd] <span dir="ltr"><<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hey,<div><br></div><div>So today I went to go and create a Debian package for FreeSWITCH using the existing packaging structure;</div>
<div><br></div><div><a href="https://github.com/traviscross/freeswitch/blob/master/debian/" target="_blank">https://github.com/traviscross/freeswitch/blob/master/debian/</a></div>
<div><a href="http://wiki.freeswitch.org/wiki/Debian_packages_buildscript" target="_blank">http://wiki.freeswitch.org/wiki/Debian_packages_buildscript</a></div><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>So I have a couple of questions;</div><div><br></div><div>1) Why are the modules separated into individual files? </div><div><br></div><div>2) Are there any reasons to not be using pbuilder?</div><div>
<br></div><div>I have also CC'd Travis Cross who appears to a major contributor on the Debian packaging code.</div><div><br></div><div>Thanks</div><span><font color="#888888"><div><br></div><div>Cal</div>
</font></span><br></div></div>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div>