Sounds like a plan, there are a number of people all building this in their own way. I've started uploading mine. key is at http://apt.cassidywebservices.co.uk/key so wget -O - http://apt.cassidywebservices.co.uk/key | apt-key add - and add line to sources: deb http://apt.cassidywebservices.co.uk/ wheezy main for wheezy At the moment only squeeze and wheezy amd64 packages are there, I'll get the others up throughout the day. On 16 March 2013 00:21, Anthony Minessale <anthony.minessale@gmail.com>wrote:

Work with ken and we can combine forces and release packages too. On Mar 15, 2013 6:29 PM, "Andrew Cassidy" <andrew@cassidywebservices.co.uk> wrote:

...

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

...

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

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

_________________________________________________________________________ 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

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too. I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us. To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default. I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package. Any thoughts? Cal On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org> wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com> wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" <andrew@cassidywebservices.co.uk> wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

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

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

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here. $ apt-cache search apache2 | grep apache | wc -l 97

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is. If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things. If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local. [1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk> wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us.

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org> wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> > wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" <andrew@cassidywebservices.co.uk< http://andrew@cassidywebservices.co.uk> > wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

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

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

That's open for debate.. there are several packages that develop at rapid speeds (such as nginx), and they still make it into the official repos. Ultimately getting this into official repos will mean more time and public contributions, the more work there is then the less chance there is of getting it done, unless it's being sponsored by a core developer or dedicated members of the community. And if it's done for one OS, then it should be done for all of them (e.g. Redhat). Personally, I think the benefits of having it in the official repos are negligible, and the time saved could be better spent on improving FreeSWITCH functionality. The FreeSWITCH mirror needs maintenance.. the index page is so big that it crashes my browser, and there are no updates for 2013. $ curl "http://files.freeswitch.org/repo/deb/debian/pool/main/f/freeswitch/" | grep "2013" | wc -l 0 Someone (or multiples) would have to step up for the role of package maintenance.. this should include keeping the changelog up to date, choosing which releases are worthy of a package (rather than a nightly deb package build, which ends up with upgrade incompatible version/release numbers - _1.3.4~n20121112T020614Z~b422-1~wheezy+1_amd64), and preferably keeping the debian/* up to date as well. Cal On Sat, Mar 16, 2013 at 6:55 PM, Avi Marcus <avi@avimarcus.net> wrote:

At the speed that FS updates, I don't particularly see the point of getting it into the official repos...

-Avi

On Sat, Mar 16, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

...

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

...

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here.

$ apt-cache search apache2 | grep apache | wc -l 97

...

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

...

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is.

If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things.

If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local.

[1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk> wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us.

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org> wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> > wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" < andrew@cassidywebservices.co.uk <http://andrew@cassidywebservices.co.uk>

...

wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

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

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

_________________________________________________________________________ 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 think the core devs will ultimately have to be the ones that make the final decision on whether or not we should be aiming for official repos. Once that has been decided, we can then make plans on how we're going to approach package maintenance. Ken - can you make the final decision on this? Cal On Sat, Mar 16, 2013 at 8:37 PM, Ken Rice <krice@freeswitch.org> wrote:

Getting it into official repos only helps gain wider adaption, many people wont even try something if they cant just type ${package_manager} install ${application}

On 3/16/13 12:55 PM, "Avi Marcus" <avi@avimarcus.net> wrote:

At the speed that FS updates, I don't particularly see the point of getting it into the official repos...

-Avi

On Sat, Mar 16, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here.

$ apt-cache search apache2 | grep apache | wc -l 97

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is.

If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things.

If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local.

[1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us.

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org < http://krice@freeswitch.org> > wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> <http://anthony.minessale@gmail.com>

...

wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" <andrew@cassidywebservices.co.uk< http://andrew@cassidywebservices.co.uk> < http://andrew@cassidywebservices.co.uk> > wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

Cal

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <http://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://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

If that's what's stopping them from trying FS, especially if there is a .deb ready and waiting, then I expect the community will have to answer a LOT of very basic questions from them that are already answered on ML / wiki / book... -Avi On Sat, Mar 16, 2013 at 10:37 PM, Ken Rice <krice@freeswitch.org> wrote:

Getting it into official repos only helps gain wider adaption, many people wont even try something if they cant just type ${package_manager} install ${application}

On 3/16/13 12:55 PM, "Avi Marcus" <avi@avimarcus.net> wrote:

At the speed that FS updates, I don't particularly see the point of getting it into the official repos...

-Avi

On Sat, Mar 16, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here.

$ apt-cache search apache2 | grep apache | wc -l 97

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is.

If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things.

If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local.

[1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us..

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org < http://krice@freeswitch.org> > wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> <http://anthony.minessale@gmail.com>

...

wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" <andrew@cassidywebservices.co.uk< http://andrew@cassidywebservices.co.uk> < http://andrew@cassidywebservices.co.uk> > wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

Cal

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <http://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://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

Hi Andrew, You can actually replace all of that functionality using pbuilder, it basically wraps debootstrap and works flawlessly with dpkg-buildpackage. This makes it much easier to do multi distribution builds, and pbuilder is pretty much Debian standard. Cal On Sat, Mar 16, 2013 at 9:29 PM, Andrew Cassidy < andrew@cassidywebservices.co.uk> wrote:

I sadly work full time this FreeSWITCH stuff is on the side. I'm fine with setting up our own repo, it's not a big deal.

I've not uplaoded any more packages as it's labelling my sid builds as wheezy! probably some side effect or maybe I even set up the chroot wrong.

As I probably can't make the call, here's what I've done:

Created chroot environments using debootstrap

Created a prereq scripts that installs all prerequisite packages

Copied the build script to build and package freeswitch

I then have 4 other scripts,

1. Copies the build and prereq into all the chroot environemnts 2. chroots into each and runs the prereq 3. chroots into each and builds FreeSWITCH

That's all there is to my setup.

On 16 March 2013 20:12, Avi Marcus <avi@avimarcus.net> wrote:

...

If that's what's stopping them from trying FS, especially if there is a .deb ready and waiting, then I expect the community will have to answer a LOT of very basic questions from them that are already answered on ML / wiki / book...

-Avi

On Sat, Mar 16, 2013 at 10:37 PM, Ken Rice <krice@freeswitch.org> wrote:

...

Getting it into official repos only helps gain wider adaption, many people wont even try something if they cant just type ${package_manager} install ${application}

On 3/16/13 12:55 PM, "Avi Marcus" <avi@avimarcus.net> wrote:

At the speed that FS updates, I don't particularly see the point of getting it into the official repos...

-Avi

On Sat, Mar 16, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here.

$ apt-cache search apache2 | grep apache | wc -l 97

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is.

If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things.

If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local.

[1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us.

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org < http://krice@freeswitch.org> > wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> <http://anthony.minessale@gmail.com>

...

wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" < andrew@cassidywebservices.co.uk <http://andrew@cassidywebservices.co.uk> <http://andrew@cassidywebservices.co.uk> > wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

Cal

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <http://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://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

_________________________________________________________________________ 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

I have to agree on this part and one of the reasons why I don't feel strongly either way on whether it gets included in the official repos or not. My own view is that I'm willing to overlook a package not being included in the official repos, providing that either a third party repo or individual deb file downloads are available, and sufficient instructions have been given to explain the installation instructions. There are many examples of this, for example nginx, php 5.3 dotdeb repo, Percona MySQL, saltstack and many other important stack components. There are obviously some benefits of being included in an official repo, but maintaining your own repo (as Percona do) can sometimes be much more beneficial. Cal On Sat, Mar 16, 2013 at 10:07 PM, Michael Whapples <mwhapples@aim.com>wrote:

Possibly a bit unfair to say, it can be a matter of discoverability.

To explain what I do when searching for software to meet my needs.

I will first look for software in distribution specific resources, including the package manager and distribution's wiki. If there is something mentioned there then it most likely is going to be the simplest and quickest option to get it running (the package manager should do all the dependency checks, get the require dependencies and configure the system), distribution documentation is most likely to discuss software which works well under that distribution or comment on specific things which need doing on that distribution.

If at this point I have found something which meets my needs then I need not look further. However should I not be satisfied with the options at this point I will of course look further.

Also I will read documentation, search the internet for solutions to problems, etc.

My point being though, I might not find software which is not in a official distribution if something which can do the job is in the official distribution. This is not because I am being lazy but rather I want to use my time efficiently, I prefer to use software than search for it.

Michael Whapples

On 16/03/2013 20:12, Avi Marcus wrote:

If that's what's stopping them from trying FS, especially if there is a .deb ready and waiting, then I expect the community will have to answer a LOT of very basic questions from them that are already answered on ML / wiki / book...

-Avi

On Sat, Mar 16, 2013 at 10:37 PM, Ken Rice <krice@freeswitch.org> wrote:

...

Getting it into official repos only helps gain wider adaption, many people wont even try something if they cant just type ${package_manager} install ${application}

On 3/16/13 12:55 PM, "Avi Marcus" <avi@avimarcus.net> wrote:

At the speed that FS updates, I don't particularly see the point of getting it into the official repos...

-Avi

On Sat, Mar 16, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here.

$ apt-cache search apache2 | grep apache | wc -l 97

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is.

If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things.

If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local.

[1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us.

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org < http://krice@freeswitch.org> > wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> <http://anthony.minessale@gmail.com>

...

wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" < andrew@cassidywebservices.co.uk <http://andrew@cassidywebservices.co.uk> <http://andrew@cassidywebservices.co.uk> > wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Hello,

I've recently released an alternative Debian package builder for FreeSWITCH.

https://github.com/foxx/freeswitch-debian

Although FreeSWITCH does already have suitable Debian packages (and a builder), it might not be suitable for your needs (and in our specific use case, we required an alternative approach).

Some of the reasons for this might be;

* Build your own packages with custom patches applied * Your build system requires an easy to use, 1 command buider * Building your own source packages from GIT for security reasons * Have a single Debian package to install rather than 100+

It supports the following features;

* Uses 'get-packaged-orig-source' to fetch original source from FreeSWITCH git * Builds as non-native, all arch package using quilt 3.0 patching (in accordance with Debian guidelines) * Uses start-stop-daemon * Uses pbuilder to ensure a clean build * Creates 'freeswitch' system user and enforces permissions on FreeSWITCH files * Installs into /opt/freeswitch, rather than system dirs * Removing/purging package will NOT remove data/logs dir or delete 'freeswitch' system user (in accordance with Debian guidelines) * Enforces all necessary dependancies

Usage:

# Replace GIT_REF with the ref from GIT you wish to compile against # Replace FS_VERSION with the version of FreeSWITCH we are compiling

$ apt-get install git $ git clone https://github.com/foxx/freeswitch-debian.git $ cd freeswitch-debian $ GIT_REF=master FS_VERSION=1.3.16 make

Hope this helps someone else!

Cal

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <http://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://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

_________________________________________________________________________ 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

Cal's way seems better, perhaps we could go down that route? I think between us we can easily donate storage space for an apt repository. I set up mine using reprepro using various guides, one of them here: http://blog.jonliv.es/2011/04/26/creating-your-own-signed-apt-repository-and... On 18 March 2013 03:02, Michael Jerris <mike@jerris.com> wrote:

Some of what we do with forked libraries will never get in to os repos. If anyone feels particularly strongly about things going in to os distro, they would first need to resolve working on pushing our patches upstream to appropriate open source packages. This has not been a hight priority for the core dev team, but we are open to answering any questions if someone wants to do that. This would be the first pre-requisite before we could even discuss what is necessary to get into any of the OS distros.

Mike

On Mar 16, 2013, at 4:37 PM, Ken Rice <krice@freeswitch.org> wrote:

Getting it into official repos only helps gain wider adaption, many people wont even try something if they cant just type ${package_manager} install ${application}

On 3/16/13 12:55 PM, "Avi Marcus" <avi@avimarcus.net> wrote:

At the speed that FS updates, I don't particularly see the point of getting it into the official repos...

-Avi

On Sat, Mar 16, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here.

$ apt-cache search apache2 | grep apache | wc -l 97

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is.

If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things.

If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local.

[1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us.

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org < http://krice@freeswitch.org> > wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> <http://anthony.minessale@gmail.com>

...

wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" <andrew@cassidywebservices.co.uk< http://andrew@cassidywebservices.co.uk> < http://andrew@cassidywebservices.co.uk> > wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

_________________________________________________________________________ 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

Sorry guys I missed the wednesday call, was there any important points taken from it? Cal On Mon, Mar 18, 2013 at 11:16 AM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

Personally I'd say using reprepro for FS is a bit too simplistic for what we need (for example, it doesn't support multiple versions of the same package).. that blog URL you posted was actually the same one I tried in my first ever attempt :)

The best middle-ground solution I've found so far is mini-dinstall, it automates a lot of the process for the most part, and supports multiple versions of the same package in the same repo - although if anyone has any other suggestions/thoughts, it'd be good to discuss.

Cal

On Mon, Mar 18, 2013 at 9:22 AM, Andrew Cassidy < andrew@cassidywebservices.co.uk> wrote:

...

Cal's way seems better, perhaps we could go down that route? I think between us we can easily donate storage space for an apt repository. I set up mine using reprepro using various guides, one of them here:

http://blog.jonliv.es/2011/04/26/creating-your-own-signed-apt-repository-and...

On 18 March 2013 03:02, Michael Jerris <mike@jerris.com> wrote:

...

Some of what we do with forked libraries will never get in to os repos. If anyone feels particularly strongly about things going in to os distro, they would first need to resolve working on pushing our patches upstream to appropriate open source packages. This has not been a hight priority for the core dev team, but we are open to answering any questions if someone wants to do that. This would be the first pre-requisite before we could even discuss what is necessary to get into any of the OS distros.

Mike

On Mar 16, 2013, at 4:37 PM, Ken Rice <krice@freeswitch.org> wrote:

Getting it into official repos only helps gain wider adaption, many people wont even try something if they cant just type ${package_manager} install ${application}

On 3/16/13 12:55 PM, "Avi Marcus" <avi@avimarcus.net> wrote:

At the speed that FS updates, I don't particularly see the point of getting it into the official repos...

-Avi

On Sat, Mar 16, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:

On Sat, Mar 16, 2013 at 7:16 PM, Ken Rice <krice@freeswitch.org> wrote:

So that’s 1 for 10AM Eastern (CDT) or 2PM GMT Wed.

The problem with installing all the modules is that you don’t always need or want them installed on the system. And there are a huge number of people doing embedded work with FreeSWITCH. Take Apache as another example a quit apt-cache search apache2 shows dozens of apache2 packagesthat you must install to get that functionality after the fact.

Actually you do have a good point here.

$ apt-cache search apache2 | grep apache | wc -l 97

The whole point of meta packages or config packages for FreeSWITCH is to try and keep this consistant across all platforms be it RHEL/Centos or Debian or even Ubuntu. This reduces the amount of bandwidth required to supporting the various things after FS has been installed.

Personally if it were up to me I would say screw all the different variations between how FHS and other file layouts work and say pick one of the following, /opt/freeswitch or /usr/local/freeswitch we are going to install everything in those locations. This would drastically reduce support issues and greatly improve the ability of users to backup and change things in FS w/out having to search the entire filesystem to figure out where something as simple as freeswitch/db/zrtp.dat is located.

In Debian packaging etiquette (afaik), /opt/ is used usually for non-free packages, or packages where the source code is not given out and moving files around would break the pre-compiled binary. If the end goal was to get FS included in the Debian mirrors, then you'd need to go beyond just /usr/local/freeswitch.. it'd have to be split into /etc/freeswitch, /var/log/freeswitch etc.

Yes I know that last statement will cause a ton of arguments with people as getting started on where things should go on a file system layout is as toxic as starting a debat on religion or politics, but that’s not the point, we are not a distribution, we are a project developing a specific software package. That being said I honestly believe the single install location is the proper thing to do, but we can have support for FHS install locations etc in the build/packaging scripts to ease distro packagers lives for getting packages into the main distro repo’s. But even then we will still have to maintain packages for FreeSWITCH proper repos as you already know how hard it is to get the latest release of software for many thing (for crying out loud, centos still ships Postgresql 8, and they are up to 9.2.3)

It really depends what the agreed end goal is.

If we want to one day have it in the various OS mirrors, then it'll have to be done properly. This will increase complexity, and end up with more time needing to be spent. Packaging is a skill/art in its own rights, and you'd need dedicated people to work on packaging for the various OS's. Personally, I think the only benefit for splitting up the layout would be if you want to get it included in the official OS mirrors. However if this is not the case, then having it all inside a single directory is going to be quicker and easier, leaving people with more time to focus on other things.

If having it under a single dir is agreed, according to [3], /etc/opt is expected to store configuration files related to packages inside /opt, the use of /usr/local [1] and /opt [2] appears to be OS specific [4]. I don't have any strong opinions of whether it should be /opt or /usr/local.

[1] /usr/local - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-29 [2] /opt - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-.2Fopt-... [3] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard [4] http://stackoverflow.com/questions/12649355/what-does-opt-mean-as-in-the-opt...

K

On 3/16/13 11:14 AM, "Cal Leeming [Simplicity Media Ltd]" < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

Sure I'm up for that, though I think discussing a bit more on email before hand would be a good idea too.

I can do 10am Eastern on Wednesday, which would be 2pm GMT/UK time for us.

To clarify my own position on packaging.. Having the packages split into their individual modules is a nice idea in theory, but it doesn't feel like the 'Debian way'. Most Debian users are used to only installing just a few packages, and the package maintainer decides what should be compiled in by default (take nginx for example). The application then decides which modules should be loaded in using the .so files (for example Apache). The exception to this is Python, where you have external Python modules (such as python-curl), however these not part of the Python core, thus why they are kept separate. Standard python modules (such as zlib) are all included by default.

I don't know enough about how FreeSWITCH module linking works, but I would have thought that if a module is compiled dynamically, then it won't be linked in unless it's specified in modules.conf.xml. In which case, you could just have a single package with all the dynamic modules compiled in, and you would change which modules are loaded in by editing your modules.conf.xml. On that basis, I think that the modules should be compiled as a single package.

Any thoughts?

Cal

On Sat, Mar 16, 2013 at 5:18 PM, Ken Rice <krice@freeswitch.org < http://krice@freeswitch.org> > wrote:

Debian Packages... Why don’t you guys all get together on the FS conf bridge, and lets get everyone working together to get these done in a common way... Hows Say Noon Eastern on Tuesday for 10 Eastern on Wed (an hour before the regular weekly call) to get all you guys in 1 bridge to nail this down.

On 3/15/13 6:21 PM, "Anthony Minessale" <anthony.minessale@gmail.com < http://anthony.minessale@gmail.com> <http://anthony.minessale@gmail.com>

...

wrote:

Work with ken and we can combine forces and release packages too.

On Mar 15, 2013 6:29 PM, "Andrew Cassidy" < andrew@cassidywebservices.co.uk <http://andrew@cassidywebservices.co.uk> <http://andrew@cassidywebservices.co.uk> > wrote:

I just wrote a script that chroots and builds for each env I have installed using the provided build scripts.

On 15 March 2013 20:27, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk < http://cal.leeming@simplicitymedialtd.co.uk> < http://cal.leeming@simplicitymedialtd.co.uk> > wrote:

_________________________________________________________________________ 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