asterisk-core-sounds - extra sound files of asterisk

[Tzafrir Cohen]

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:
>>>
>>>>> Another issue: should those files be installed directly at  
>>>>> /usr/share/asterisk/sounds/LANG (e.g.: LANG=en)? or do we want to 
>>>>> avoid that, and make it something along the lines of en_digium or 
>>>>> en_US ?
>>>>
>>>> In order to avoid potential collisions, I wanted to use the semy  
>>>> standard schema of:
>>>>
>>>>  ${lang}_${country}_${gender}_${description}.
>>>>
>>>> Thus the prompts we have are:
>>>>
>>>> en_US_f_Allison
>>>> es_MX_f_Allison [*]
>>>> fr_CA_f_June
>>>>
>>>> This all works fine if LANGUAGE was set. But what if it isn't?
>>>
>>>> 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 believed Java used it too but I notice now that apparently they only  
> use it for files.
>
>
>> And more importantly, we have three "alternatives' pointing to the same 
>> target.
>
> I do not understand what issue you describe here: isn't multiple  
> alternatives exactly the point of using the elternatives mechanism in  
> the first place?!?
>
>
>> 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.

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

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.

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

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

>
>
>> Beyond that, it is up to the sysadmin to manage things using 'ln -s'
>
> Sysadmins should not mess below /usr/share. Please do not encourage  
> that!

Anyway, packages of asterisk-prompt-es and asterisk-prompt-fr-* with
this are now available under http://updates.xorcom.com/pkg-voip/ .

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