asterisk-core-sounds - extra sound files of asterisk

Sat Mar 20 21:55:50 UTC 2010

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

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

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

>
>> Also note that in order to do that (or to add an unpackaged sounds set) 
>> a user (sysadmin) will need to understand 'update-alternatives  
>> --install', which is quite more complex than 'ln -s'. This is another  
>> use case I have in mind.
>
> You avoid addressing the issue of user messing with an area of the  
> system intended for the packaging system to "own".
>
> Yes, it sure is easier to mess directly with the filesystem - but  
> completely unreliable to then afterwards use the packaging system on top  
> of a locally customized filesystem.

I've tried addressing the issue. All possible solutions I got were
overly-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.

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).
>
>
>
>>>>> Anyone who cares about those files will also care about the setup 
>>>>> of them being deterministic and reliably overridable.
>>>>
>>>> It's simple to override manually.
>>>
>>> Anything is possible manually.
>>>
>>> What you tell me is that Debian-Edu and other Debian Pure Blends  
>>> cannot use Debian interfaces for atypical Asterisk setups, but need  
>>> to add post-install hacks that mess directly with the filesystem.  
>>> That's bad!
>>
>> If you have a custom install of Asterisk with more than 2 packages of  
>> the same language, I would suspect you'll set up LANGUAGE explicitly.
>
> Yes, I got the impression that that is what you expect of me.  I just  
> really really really would like to convince you to support more more  
> complex setups out of the box.
>
> I really do not expect it to be very complex to support - the tough part  
> is to recognize the need of it, it seems (from this conversation) :-)

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