asterisk-core-sounds - extra sound files of asterisk

Sat Mar 20 18:25:17 UTC 2010

On Sat, Mar 20, 2010 at 05:33:50PM +0100, Jonas Smedegaard wrote:
> On Sat, Mar 20, 2010 at 05:44:30PM +0200, Tzafrir Cohen wrote:
>> On Sat, Mar 20, 2010 at 03:33:59AM +0100, Jonas Smedegaard wrote:
>>> Hi Tzafrir (and others),
>>>
>>> On Fri, Mar 19, 2010 at 10:10:25PM +0200, Tzafrir Cohen wrote:
>>>> On Sat, Mar 06, 2010 at 11:17:55PM +0100, Jonas Smedegaard wrote:
>>>>> On Mon, Feb 22, 2010 at 11:31:15PM +0200, Tzafrir Cohen wrote:
>>>>>> A follow-up:
>>>>>>
>>>>>> On Mon, Jan 18, 2010 at 05:36:19PM +0200, Tzafrir Cohen wrote:
>
>>>>>> So, do we make /usr/share/sounds/en a symlink? Or more direct  
>>>>>> symlinks? This collides with the current asterisk-sounds 
>>>>>> package that places files in /usr/share/sounds/en (it is 
>>>>>> basically the same as asterisk-core-en-gsm).
>>>>>
>>>>> I'd suggest to...
>>>>>
>>>>>  1. Update package using /usr/share/sounds/$LANG directly
>>>>>  2. use /etc/alternatives, allowing local admin to override default
>>>>
>>>> That does not seem to work. update-alternatives doesn't work well  
>>>> with directories.
>>>
>>> What is broken about it?
>>>
>>> mplayer seems to use it for default skin.
>>
>> Well, "broken" may be a strong word. But I have to check in advance  
>> that the directory does not exist.
>
>
>
>>>> I'll have to manage something complex on my own.
>>>
>>> ...and reinvent the wheel? :-(
>>
>> Because I want a square one :-)
>
> :-)
>
>
>> * I consider a direct relative symlink better than an absolute symlink
>>  to /etc/alternatives and back.
>>
>> * I prefer a direct symlink. Following a symlink to /etc/alternatives is
>>  confusing.
>
> Above seems a single point to me.  I agree that the Debian way of doing  
> things are not always the most pleasing to the eye.  But there are  
> always good reasons for doing things the Debian ways, even if looking  
> ugly at first glance.  Always.
>
>
>> * Typically no more than two "alternatives" will be installed on the same
>>  system. Thus users will typically have no use of the extra goodies
>>  update-alternatives provides .
>
> Complexities are typically really needed only for the not-so-typical  
> cases.
>
> Please offer support for more than "typical" cases.
>
> 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).

Thus the fact that a setup is multi-lingual has no effect on the use
case.

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.

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.

>
>
>> But most importantly:
>>
>> * I have three packages all providing the same alternative (core sounds
>>  of formats gsm, g722 and wav of each of the three languages). I have  
>> to make only the last of them remove the alternative. Or provide an  
>> extra layer of indirection.
>
> Yes.  Seems again only to be "not pleasant looking" rather than a real  
> problem. Right?

This requires extra book-keeping that will have to be replicated in many
scripts. It is also an extra layer of complexity on top of
update-alternatives. If we do our own book-keeping, why do we need
update-alternatives?

>
>
>>>> Seems like a simple and more manual symlink will do:
>>>>
>>>> At postinst:
>>>>
>>>>  If there's no symlink: create a symlink to my package's directory
>>>>
>>>> At postrm:
>>>>
>>>>  If the symlink is dandling: remove it.
>>>
>>> In other words, whatever package happen to get installed first wins,  
>>> with no way to programmatically control.  That sound pretty bad! :-(
>>
>> I know. I'm not happy with it. OTOH, it's simpler and easier to  
>> understand.
>
> I suspect you mean it is simpler if messing directly below /usr/share -  
> but noone should do that anyway!
>
> I believe it is simpler for a bunch of packages potentially provided by  
> different developers to use the standard update-alternatives ABI than  
> some new invention.
>
> 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.

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

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

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