[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New options for freeswitch
On Tue, Oct 16, 2012 at 11:34 PM, D'Arcy J.M. Cain <darcy%netbsd.org@localhost>
> 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
>> 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
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
Julio Merino / @jmmv
Main Index |
Thread Index |