Re: New options for freeswitch

[Julio Merino <julio%meroh.net@localhost>]

On Tue, Oct 16, 2012 at 11:34 PM, D'Arcy J.M. Cain <darcy%netbsd.org@localhost> 
wrote:
> 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.

"Probably", but not always.  As a user of binary packages, it's
annoying when the defaults chosen by the maintainer don't satisfy my
needs and those defaults could have been avoided if I had been given
the choice by virtue of multiple binary packages.

Yes, sometimes this is not doable (like when the option changes the
way a binary is built), and in this case it's fine to use an option
and provide a reasonable default.  However, when a binary
package-friendly choice is present, options should be avoided: they
are just an easy way out from doing "the right thing".

I don't know why pkglint tells you to ask for comments on the addition
of new options, but I suspect the reason is two folded: first, to make
sure that the name is acceptable; and second, but most importantly, to
ensure that new options are not introduced when an alternative is
available.

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

Aha.  Then, this meta-package could just depend on the software
package and on the specific sub-packages for the audio files that are
reasonable defaults.

This way, if a user of binary packages does not like the audio files
being pulled in by the meta-package, he is free to skip the
meta-package altogether and just install the individual components.

(I'm also willing to accept options to tune the specific
*dependencies* of a meta-package; I think that's an acceptable benefit
of options.  Not sure if this is what you were after in the first
place...)

-- 
Julio Merino / @jmmv