asterisk-core-sounds - extra sound files of asterisk

Sat Mar 20 20:38:13 UTC 2010

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.

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

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

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.

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

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

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

>I would also like to remind you of http://updates.xorcom.com/iso/ (BTW: 
>2.1.0 is out). I'm very well aware of issues with packaging. While not 
>a Pure Blend, almost all non-lenny packages there are direct backports 
>from the pkg-voip repo (potentially using the debian/backports/lenny 
>script).

Thanks.  I will certainly have a closer look.

I cannot access the data from my current machine, however, as it is 
using squashfs 3.1 which my currently running Debian on my laptop is too 
new to support.  Also it seems the CD uses standard packages backported 
to Lenny - if that is so, then I see little relevancy for looking 
closer, as my intend is not to have an Asterisk-only system but 
integration of Asterisk with one or more Pure Blends.

Kind regards,

  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20100320/9a41f951/attachment-0001.pgp>