[Freeswitch-users] Debian packaging - some questions

Ken Rice krice at freeswitch.org
Tue Mar 12 17:37:40 MSK 2013


There are 2 change logs already that can be used to update debian/changelog

1. git log  (yes I know not really a changelog but it can be derived from
there) 
2. docs/ChangeLog this is the main changelog. Its not always 100% up to date
but its there

If you wish to contribute patches to the ChangeLog please do so they are
welcomed the main committers don¹t always have time to update these
things...

One of the biggest things the project as a whole needs is dedicated
documenters that will help with these things.

K


On 3/12/13 7:15 AM, "Steven Ayre" <steveayre at gmail.com> wrote:

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

-- 
Ken
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
irc.freenode.net #freeswitch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130312/7bbed154/attachment.html 


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list