[Frugalware-devel] add default phonon backend

Michel Hermier hermier at frugalware.org
Mon Jun 20 23:19:45 CEST 2011


> On Wed, Jun 8, 2011 at 4:16 AM, Michel Hermier <hermier at frugalware.org>
> wrote:
>>> On Wed, Jun 8, 2011 at 12:12 AM, Michel Hermier
>>> <hermier at frugalware.org>
>>> wrote:
>>>> Upstream said null backend is unsuported (yet).
>>>> Ihought I decided to choose a different approch. I made the rodepends
>>>> in
>>>> the phonon user (libknotify) and not in phonon itself to give us a
>>>> chance
>>>> to not have premature hidden dependecies to the backend dependencies.
>>>> So now only the move of phonon-backend-xine is left.
>>>>
>>>
>>>  Sounds pretty much OK to me. So the next step would be to move the
>>> rodepends to the phonon package itself ?
>>
>> No, the second step is only to move phonon-backend-xine out of -extra.
>>
>>>  I'm not really sure what you mean by premature hidden dependecies.
>>> How can those be detected with the current change ?
>>
>> It can't be detected yet, but it's a question of packaging logic.
>> Since I don't want all the packages that depends on phonon to see that
>> xine is automagically added, because It needs a default backend, I have
>> to
>> move the depends in some of it's dependencies. It as 2 adventages.
>> - The backend is really added when/where needed (and since real phonon
>> user are low it's not really a matter).
>> - All the package that needs phonon, see xine later. That means, if we
>> change the default phonon package, we don't have to add xine in
>> rodepends
>> just in case some hidden dependency become visible.
>>
>
>  OK but I have a question here. What if I just install Amarok and not
> KDE ? Will it add a phonon backend ? If not Amarok won't work, I mean
> it won't play any sound which is not good for a music player.
>  I think I understand what you mean now. Let's say package C depends
> on package B that depends on Phonon. User wants to add package C , it
> will pull in Phonon which will then pull in the xine backend which you
> would like to avoid, right ?

It's a bit complicated but in the facts libkdeui depends on the
notification presence. So any user of KAction will have have a phonon
backend. And guess what all kde applications depends on that fact ^_^
so amarock also.

No I didn't wanted to avoid the phonon backend. I just don't wanted to
introduce it this low, in the system.

>  But then another backend would have to be explicitly installed if
> Phonon is going to be of any use, otherwise it just won't work.
>
>>>  Oh and thanks.
>>
>> No Problem (thought, I would have prefered to have phonon allowing null
>> backend and not barfing on the floor like a dumb)
>>
>>
>
>  I don't think null backend or pulseaudio backend would be an option.
> That's because phonon is designed to work with a valid backend that
> will do the playback itself. Without it it just won't play any audio ,
> it's just a (really) dumb wrapper unfortunately.

Thought a null backend should allways be a safe fallback, and just not
crash. As an example if a lib changed and the backend is not able to load
correctly. This is not a good option to fail in such simple *common*
issue.



More information about the Frugalware-devel mailing list