Re-inventing the FreeSWITCH port
kozlov.sergey.404 at gmail.com
Mon Feb 10 13:01:40 UTC 2014
I'm working on re-inventing the FreeSWITCH port. The previous FreeSWITCH
port was deleted not so long ago and the current -devel variant is outdated.
I've already ported and patched some relatively simple ports, but
FreeSWITCH is completely different case.
The software consists of the core (which is pretty useless alone) and
151 modules which add functionality to the core, 45 of which are
considered the default packaging.
The main questions are:
1. What architecture is the best for this kind of port?
The options are:
a. Create one freeswitch-core port, 151 freeswitch-mod_foobar ports
and a freeswitch metaport which will bring in the core and all the
modules from the default packaging?
b. Create one freeswitch port with 151+ options and default
packaging modules declared as default options
c. Option (b) with the freeswitch-full MASTERDIR port which installs
all the modules
d. Your option
2. When should I post the first version of the port?
The thing is that every module needs it's own distfiles, dependencies,
patches, plist entries and so on. Every module needs as much effort as a
small port, and thoughts that i need to properly write options, patches,
plist entries and everything else for 151 modules drive me crazy. Now
I've managed to correctly build the default packaging. If I used option
(b) from the first question then I could create the freeswitch port
without options, a static plist and post it right away, making all the
changes afterwards. This will create a freeswitch binary package which
will be ready to use and won't change much later.
3. Testing the port.
The complexity of this port makes me think it will be full of build
errors, which will produce suboptimal or broken binaries. How to ask to
consider this port experimental? Should I only write the warning message
in pkg-message or maybe something else?
Any help is greatly appreciated.
More information about the freebsd-ports