asterisk-core-sounds - extra sound files of asterisk
Tzafrir Cohen
tzafrir.cohen at xorcom.com
Sun Mar 21 05:00:01 UTC 2010
On Sun, Mar 21, 2010 at 03:16:33AM +0100, Jonas Smedegaard wrote:
> On Sat, Mar 20, 2010 at 11:55:50PM +0200, Tzafrir Cohen wrote:
>> On Sat, Mar 20, 2010 at 09:38:13PM +0100, Jonas Smedegaard wrote:
>>> On Sat, Mar 20, 2010 at 08:25:17PM +0200, Tzafrir Cohen wrote:
>>>> On Sat, Mar 20, 2010 at 05:33:50PM +0100, Jonas Smedegaard wrote:
>>>
>>>>> I am right now working on Asterisk setup for Debian-Edu, which
>>>>> may involve multi-lingual support in unusual languages. Not a
>>>>> "typical" case, I suspect.
>>>>
>>>> The symlinks (and potentially the alternatives) are for
>>>> /usr/share/asterisk/sounds/xx (where 'xx' may currently be 'en',
>>>> 'fr' and 'es', but can be any language code).
>>>
>>> Please handle alternatives for both 'xx' and 'xx_YY' style locales,
>>> allowing multiple mexican spanish voices to compete for the "es_MX"
>>> location.
>>
>> The reason I have special handling for 'xx' is because Asterisk has
>> special handling for the LANG (LANGUAGE with the first '_' and anything
>> following it is removed). And more so for for 'en' which is the
>> fallback in case no other language was set (though a different fallback
>> could be set in asterisk.ocnf).
>
> Oh, Asterisk really handles gettext-style LANG specially? Please point
> me to more documentation on that - I have failed to find other info than
> that it maintains a LANGUAGE string which happens to default to "en".
> Automatic stripping of underscore and remaining parts is news to me.
>
> Nvertheless I see nothing wrong about our packaging supporting
> language+locale (i.e. xx_YY) style alternatives too, even if Asterisk
> itself has no special handling of it: When then explicitly declaring a
> language+locale (instead of only a language) we are able to have
> multiple packages fulfill such need.
>
>
>>>> Thus the fact that a setup is multi-lingual has no effect on the use
>>>> case.
>>>
>>> Wrong choice of words on my part then. Please see below for more
>>> details...
>>>
>>>
>>>> What I mean by "typical" is "no more than a single set of prompts
>>>> installed for each language. That is, you will not have both the Digium
>>>> es_MX prompts package and the existing asterisk-prompt-es (which is
>>>> es_ES) installed on the same system.
>>>>
>>>> And if you will, you'll likely to rely on an exact value of LANGUAGE
>>>> and not rely on the default. You actually may prefer the default to be
>>>> an explty directory.
>>>
>>> Let me try construct a case: A mexican school installs a future version
>>> of Debian-Edu:
>>>
>>> a) Skolelinux has a fundamental principle of a completely automated
>>> install process (the math teacher granted a few hours per week on
>>> maintaining the school computers should spent all that time on user
>>> issues so cannot be burdened with technical config details of
>>> individual service on the servers). In other words: Local admin
>>> should *not* do anything "simple", just start the installation.
>>> b) Skolelinux has a goal (reached in this future release) of being a
>>> "Debian Pure Blend" which (among other things) means all
>>> installation routines must be done in accordance to Debian Policy.
>>> c) Skolelinux is designed in the spirit of Debian: Even if initial
>>> install configures a very specific system, a local admin _can_
>>> derive openly from there: it is a plain standard Debian system with
>>> all the choices still there even if preselected during initial
>>> install. In other words: Selections of e.g. language packs should
>>> be locally extendable, not fixated through strict Depends and
>>> Conflicts hints.
>>> d) Asterisk is setup with 2 phone realms: "global" and "local".
>>> * The "global" realm has a multilingual menu system in a few select
>>> languages, being as general as possible.
>>> * The "local" realm is unilingual, being as specific as possible.
>>>
>>> You would probably then provide above system with an Asterisk config
>>> using e.g. "es_ES_female_Westany" for spanish part of global realm and
>>> e.g. "es_MX_female_Westany" for the local realm.
>>
>> Where do you set the language?
>>
>> If you set the language explicitly anyway, I don't see an issue.
>
> If I set the language explicitly to "es_MX_female_Westany" then it will
> be tied to one particular implementation and I need to depend strictly
> on that one particular package providing that one particular
> implementation.
>
> What I tried to explain you was that I would like to only be explicit
> about needing a _mexican_ variant of spanish without choosing a specific
> implementation. The benefit of being able to do that is that then
> multiple packages can offer mexican spanish voices (by all providing the
> virtual package asterisk-sounds-es-mx), multiple providers can be
> installed at once, and if the local admin favor a specific one then she
> can override the ranking to tune the election process.
>
> Yes, the local admin can also just edit the config file, but really it
> will not be the local admin doing such tuning, but some metapackage part
> of the Pure Blend - and such package is forbidden to mess
> programmatically with the config files.
>
> Yes, I can then provide debconf-controlled configfile snippets, and I
> plan to do that for other things but doing it for things like selection
> of voices are so much more hassle and unintuitive than using
> update-alternatives which was invented for this very purpose.
>
>
>>> I would want to use "es" for global realm and "es_MX" for local
>>> realm, and let weight hints of update-alternatives resolve which
>>> actual voice is used in each case, depending on both a) which actual
>>> packages are installed at any given time and b) eventual local admin
>>> overriding with a custom installed voice pack installed below
>>> /usr/local/share/.
>>
>> If you have both es_ES and es_MX, I'm not sure it's wise to trust the
>> alternatives that 'es' would be es_ES.
>>
>>>
>>> Do my case make sense? Do you see my interest in using
>>> update-alternatives? Do your custom alternatives implementation
>>> cover above scenario - i.e. support *both* fully automated
>>> Policy-compliant initial setup, fully automated reelection (based on
>>> ranking) if packages are later added or removed, and ability to add
>>> manual ranking overrides?
>>>
>>> That, I believe, is what the standard Debian alternaives system
>>> provides.
>>
>> It's more complex than what I had in mind. But then again extending it
>> only takes a simple symlink. Implementing all of this with alternatives
>> would lead to much complexity.
>
> So one symlink is simple. A chain of two symlinks is too complex.
>
> You have got to be kidding me...
One is complex. Two are more complex :-)
>
>
>>>>> If you really really want another invention, then I strongly urge you
>>>>> to look at /usr/sbin/update-java-alternatives which wraps
>>>>> update-alternatives in another (simpler?) ABI.
>>>>
>>>> But my main issue is not with the command-line interface of
>>>> update-alternatives. It's with the data it uses. It identifies an
>>>> alternative by its target. This is the basic issue I have.
>>>
>>> Please elaborate. Maybe you know some details here that I am simply
>>> unaware of - I just cannot understand from the short comment right
>>> above.
>>
>> Look at
>> http://svn.debian.org/viewsvn/pkg-voip/asterisk-sounds/asterisk-core-sounds/
>> Please explain how packages from it could be used with
>> update-alternatives .
>>
>> This package builds 9 different binary packages:
>>
>> asterisk-core-sounds-{en,es,fr}-{g722,gsm,wav}
>>
>> All three asterisk-core-sounds-en-* packages install files to the same
>> directory. They install the same files with a different extension. Thus
>> they are not mutually exlcusive. And thus each of them makes that
>> directory a sane candidate for the symlink /usr/share/asterisk/sounds/en .
>> (The same applies to the two other languages).
>>
>> Thus I can't simply run 'update-alternatives --install' in the postinst
>> and 'update-alternatives --remove' in the prerm. I should only add it if
>> it was not already added (easy: just check) and remove it only if nobody
>> uses it (that's the difficult part).
>>
>> I can't think of a simple and robust definition of "nobody's using it".
>> Something that comes close i to keep an independent registry of some
>> sort of all the candidate packages. Another way is to look for some
>> specific file in the directory. But this means I have to run things in
>> the postrm. Furthermore I don't like that hueristic.
>
> Ah, I understand the issue now, I believe. Yes, update-alternatives
> handle alternatives between "atomic" objects. So the solution is simple
> as I see it:
>
> Just ship the various sound formats together. I see no problem then:
>
> asterisk-core-sounds-{en,es,fr} (each containing g722, gsm and wav)
I do.
7.7M asterisk-core-sounds-en-g722_1.4.17-1_all.deb
1.8M asterisk-core-sounds-en-gsm_1.4.17-1_all.deb
15M asterisk-core-sounds-en-wav_1.4.17-1_all.deb
Sometimes it makes sense to have just the gsm ones. In fact, in many
cases (this is what I'll probably do inthe next live CD. This is the
current default).
>
>
>
>> Another point to mention: cyclic dependencies: if you create a script
>> update-asterisk-dependencies and include it in the package asterisk (any
>> other place?), all sound packages now depend on asterisk. However
>> asterisk currently depends on having a sounds packages on the system
>> (because otherwise a number of things seem not to work).
>
> No need to ship any special script - just use plain standard
> update-alternatives.
>
> (yes it is possible to solve even if shipping a script, but no need to
> complicate matters so won't go into details on that).
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
More information about the Pkg-voip-maintainers
mailing list