[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New options for freeswitch
"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.
Main Index |
Thread Index |