tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New options for freeswitch

"D'Arcy J.M. Cain" <> writes:

> On Tue, 16 Oct 2012 21:06:42 -0400
> Julio Merino <> 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.


Home | Main Index | Thread Index | Old Index