Re: New options for freeswitch

[Aleksej Saushev <asau%inbox.ru@localhost>]

"D'Arcy J.M. Cain" <darcy%NetBSD.org@localhost> writes:

> On Tue, 16 Oct 2012 21:06:42 -0400
> Julio Merino <julio%meroh.net@localhost> wrote:
>> > Why would you split it up?  Multiple options is not tricky.  I'm
>> > just trying to get consensus on the names.
>> 
>> The reason are binary packages. Options are bad because they don't
>> give a choice to the users of your package: they'll be forced to use
>> whatever the bulk builder decided. By providing individual binary
>> packages, you allow your users to decide which one to choose.
>
> Sure but the defaults are probably fine for people using binaries.
> However, I doubt that someone building a phone switch would have a
> problem with building from source anyway.
>
>> Now... if the main FreeSWITCH package has to depend on one of the
>> various audio packages, then yes, this is not trivial because pkgsrc
>> does not offer a "Provides" mechanism.
>
> Well, it's not so much that it depends on it but it does need music to
> provide full service.  The switch will work but music on hold will be
> silent unless they build the music package or provide their own music.
>
>> But I don't know anything about FreeSWITCH, so I cannot tell how hard
>> or easy this is, or even if it makes sense. What other packages will
>> form FreeSWITCH? Will there be a meta-package that just pulls in a
>
> There will be a meta package that pulls in the music and sounds as well
> as the pizza demo if that option is selected.
>
>> variety of packages?  Will the software package depend on the audio
>> package instead?
>
> The meta package will.  The base package won't and the user is expected
> to know what they are doing.  I expect that most people will simply
> install the meta package and get the 8k and 16k music and sounds.  If
> someone really thinks they need CD quality hold music they will have
> that option.

We have examples like lang/erlang/MESSAGE already.


-- 
HE CE3OH...