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
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@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@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
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@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@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@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
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@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@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@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@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
_________________________________________________________________________ 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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
Debian's policy is to keep the changelog entries pretty short. Debian changelogs are frequently just lots of 'Updated upstream version' entries, 'Closes bug' entries when there's a Debian bug that's patched because it's not fixed upstream yet, and packaging change notes. 'git log' or 'Docs/changelog' would be too verbose. The correct thing to do according to Debian policy would be to have a short 'Updated upstream version' entry and ship the docs/ChangeLog file so a more complete history can be found in the doc folder. freeswitch/build/next-release.txt is pretty good at generating a version for Git versions, and I'd say sufficient. The issue for me is specifically when tarball releases are rolled. I believe there's a script that's run to generate them? Could that update the debian/changelog file too? Submitting ChangeLog entries against a tarball won't work unless the developers are willing to recreate the tarball. If it only gets committed to Git then it's not going to make it into a tarball until the next release, at which point it'll be out of date. -Steve On 12 March 2013 14:37, Ken Rice <krice@freeswitch.org> wrote:
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@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@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@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@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
------------------------------ _________________________________________________________________________ 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
-- Ken *http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org *irc.freenode.net #freeswitch
_________________________________________________________________________ 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
The problem is currently the changelogs are not updated on a regular basis, we could use some help in the area. If they were updated routinely it wouldn¹t really be out of day in the tarballs On 3/12/13 8:45 AM, "Steven Ayre" <steveayre@gmail.com> wrote:
Debian's policy is to keep the changelog entries pretty short. Debian changelogs are frequently just lots of 'Updated upstream version' entries, 'Closes bug' entries when there's a Debian bug that's patched because it's not fixed upstream yet, and packaging change notes. 'git log' or 'Docs/changelog' would be too verbose. The correct thing to do according to Debian policy would be to have a short 'Updated upstream version' entry and ship the docs/ChangeLog file so a more complete history can be found in the doc folder.
freeswitch/build/next-release.txt is pretty good at generating a version for Git versions, and I'd say sufficient.
The issue for me is specifically when tarball releases are rolled. I believe there's a script that's run to generate them? Could that update the debian/changelog file too? Submitting ChangeLog entries against a tarball won't work unless the developers are willing to recreate the tarball. If it only gets committed to Git then it's not going to make it into a tarball until the next release, at which point it'll be out of date.
-Steve
On 12 March 2013 14:37, Ken Rice <krice@freeswitch.org> wrote:
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@gmail.com <http://steveayre@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@gmail.com <http://steveayre@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@simplicitymedialtd.co.uk <http://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;
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@freeswitch.org <http://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://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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <http://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://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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
Thank you both Steve and Andrew for the clarification. On Tue, Mar 12, 2013 at 12:59 PM, Steven Ayre <steveayre@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.
Ah, I had previously thought this was not possible, so this makes perfect sense now.
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.
Got it, I'll have a play around and see if I can make it work.
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@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@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
_________________________________________________________________________ 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
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;
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@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 *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
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;
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@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
*T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
_________________________________________________________________________ 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
Hi, I was also integrating FreeSWITCH package compilation to our Jenkins build environment (version 1.2 and 1.3 as separate streams). You may check the configuration from the GemeinschaftPBX repo here if you're interested: https://github.com/amooma/GBE/tree/develop/misc/freeswitch Br Julian
Hi Julian, Yeah this is the kinda approach we are using at the moment. We're using a custom debian/* dir which compiles everything to a single deb package, with some of the rules and init.d stuff copied in from the original debian/* dir. $ GIT_REF=master make -- verbose snip -- ----------------------------------------- Package compiled successfully build/freeswitch_master-1_amd64.deb ----------------------------------------- This so far seems to be compiling without problem using pbuilder, which is great :) Cal On Tue, Mar 12, 2013 at 3:19 PM, Julian Pawlowski < julian.pawlowski@gmail.com> wrote:
Hi,
I was also integrating FreeSWITCH package compilation to our Jenkins build environment (version 1.2 and 1.3 as separate streams). You may check the configuration from the GemeinschaftPBX repo here if you're interested: https://github.com/amooma/GBE/tree/develop/misc/freeswitch
Br Julian
_________________________________________________________________________ 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
Hi Cal, It looks like others did rather well at answering these, so I'll just fill in some points. On 2013-03-12 12:44, Cal Leeming [Simplicity Media Ltd] wrote:
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).
It works fine with pbuilder and cowbuilder. If you take a look at the util.sh script, which is what I use to do the builds, you'll see I use cowbuilder there as well.
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.
You may not have noticed there are meta packages. If you install freeswitch-meta-all you'll get everything pulled in.
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.
Yes, that's exactly how it works.
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.
Please also be sure to read debian/README.{Debian,source}. Best, -- Travis Cross
Thank you Travis for the further clarification and thank you to everyone else who jumped on this thread, very much appreciated! Cal On Tue, Mar 12, 2013 at 3:28 PM, Travis Cross <tc@travislists.com> wrote:
Hi Cal,
It looks like others did rather well at answering these, so I'll just fill in some points.
On 2013-03-12 12:44, Cal Leeming [Simplicity Media Ltd] wrote:
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).
It works fine with pbuilder and cowbuilder. If you take a look at the util.sh script, which is what I use to do the builds, you'll see I use cowbuilder there as well.
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.
You may not have noticed there are meta packages. If you install freeswitch-meta-all you'll get everything pulled in.
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.
Yes, that's exactly how it works.
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.
Please also be sure to read debian/README.{Debian,source}.
Best,
-- Travis Cross
_________________________________________________________________________ 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
You may not have noticed there are meta packages. If you install freeswitch-meta-all you'll get everything pulled in.
You can also build your own meta package that depends on all the packages required by your application. Then it's simply a case of: $ sudo apt-get install freeswitch-meta-companyname -Steve On 12 March 2013 15:28, Travis Cross <tc@travislists.com> wrote:
Hi Cal,
It looks like others did rather well at answering these, so I'll just fill in some points.
On 2013-03-12 12:44, Cal Leeming [Simplicity Media Ltd] wrote:
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).
It works fine with pbuilder and cowbuilder. If you take a look at the util.sh script, which is what I use to do the builds, you'll see I use cowbuilder there as well.
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.
You may not have noticed there are meta packages. If you install freeswitch-meta-all you'll get everything pulled in.
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.
Yes, that's exactly how it works.
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.
Please also be sure to read debian/README.{Debian,source}.
Best,
-- Travis Cross
_________________________________________________________________________ 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
Oh damn that's a good point - well spotted Cal On Tue, Mar 12, 2013 at 5:33 PM, Steven Ayre <steveayre@gmail.com> wrote:
You may not have noticed there are meta packages. If you install
freeswitch-meta-all you'll get everything pulled in.
You can also build your own meta package that depends on all the packages required by your application. Then it's simply a case of: $ sudo apt-get install freeswitch-meta-companyname
-Steve
On 12 March 2013 15:28, Travis Cross <tc@travislists.com> wrote:
Hi Cal,
It looks like others did rather well at answering these, so I'll just fill in some points.
On 2013-03-12 12:44, Cal Leeming [Simplicity Media Ltd] wrote:
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).
It works fine with pbuilder and cowbuilder. If you take a look at the util.sh script, which is what I use to do the builds, you'll see I use cowbuilder there as well.
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.
You may not have noticed there are meta packages. If you install freeswitch-meta-all you'll get everything pulled in.
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.
Yes, that's exactly how it works.
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.
Please also be sure to read debian/README.{Debian,source}.
Best,
-- Travis Cross
_________________________________________________________________________ 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
_________________________________________________________________________ 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
I'm just running a build of the 6 scenarios I mentioned earlier (i need at least 3 of them, so why not?) I'll stick them up somewhere if there's interest. On 12 March 2013 18:42, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Oh damn that's a good point - well spotted
Cal
On Tue, Mar 12, 2013 at 5:33 PM, Steven Ayre <steveayre@gmail.com> wrote:
You may not have noticed there are meta packages. If you install
freeswitch-meta-all you'll get everything pulled in.
You can also build your own meta package that depends on all the packages required by your application. Then it's simply a case of: $ sudo apt-get install freeswitch-meta-companyname
-Steve
On 12 March 2013 15:28, Travis Cross <tc@travislists.com> wrote:
Hi Cal,
It looks like others did rather well at answering these, so I'll just fill in some points.
On 2013-03-12 12:44, Cal Leeming [Simplicity Media Ltd] wrote:
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).
It works fine with pbuilder and cowbuilder. If you take a look at the util.sh script, which is what I use to do the builds, you'll see I use cowbuilder there as well.
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.
You may not have noticed there are meta packages. If you install freeswitch-meta-all you'll get everything pulled in.
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.
Yes, that's exactly how it works.
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.
Please also be sure to read debian/README.{Debian,source}.
Best,
-- Travis Cross
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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 *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
On Tue, Mar 12, 2013 at 6:44 AM, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> 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.
Off topic a bit, but it's great to see another Salt user. We have our stuff built-out to the point where we pull the trigger on the Salt Master and 30 mins later we have a full stack (12+ systems depending on how we configure it) of load balanced and highly available servers running FreeSWITCH, OpenSIPS, nginx, HAProxy, Django, PostgreSQL, UWSGI, Postfix, etc. --all layered on top of freshly built virtual hosts running kvm/libvirt under Ubuntu 12.04 LTS (except for FS, it runs on iron). I almost get goosebumps when it's done running. I know you all do this kinda stuff all day long, but still, I can have my fun too, right? Long live Salt! :) Gabe
participants (7)
-
Andrew Cassidy
-
Cal Leeming [Simplicity Media Ltd]
-
Gabriel Gunderson
-
Julian Pawlowski
-
Ken Rice
-
Steven Ayre
-
Travis Cross