asterisk-core-sounds - extra sound files of asterisk
dr at jones.dk
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"
>Thus the fact that a setup is multi-lingual has no effect on the use
Wrong choice of words on my part then. Please see below for more
>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
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
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
>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
>>>> 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
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.
* 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
Size: 836 bytes
Desc: Digital signature
More information about the Pkg-voip-maintainers