[Freeswitch-users] Debian packaging - some questions

[Steven Ayre]

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 next-release.txt + the
date.

IMO the release tarballs should get the debian/changelog updated for
version releases - there is a Jira on that:
http://jira.freeswitch.org/browse/FS-4778

-Steve




On 12 March 2013 12:59, Steven Ayre <steveayre at gmail.com> wrote:

> 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.
>
>
> That's exactly what it's trying to do. It attempts to build every package,
> allowing you to install only what you need.
>
> 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).
>
> 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.
>
>
> 2) Are there any reasons to not be using pbuilder?
>
>
> 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.
>
>  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.
>
>
> -Steve
>
>
>
> On 12 March 2013 12:44, Cal Leeming [Simplicity Media Ltd] <
> cal.leeming at simplicitymedialtd.co.uk> wrote:
>
>> Hey,
>>
>> So today I went to go and create a Debian package for FreeSWITCH using
>> the existing packaging structure;
>>
>> https://github.com/traviscross/freeswitch/blob/master/debian/
>> http://wiki.freeswitch.org/wiki/Debian_packages_buildscript
>>
>> 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 at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130312/ce111994/attachment-0001.html