On Tue, Jun 21, 2011 at 12:19 AM, Michel Hermier <[email protected]> wrote: >> On Wed, Jun 8, 2011 at 4:16 AM, Michel Hermier <[email protected]> >> wrote: >>>> On Wed, Jun 8, 2011 at 12:12 AM, Michel Hermier >>>> <[email protected]> >>>> 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. > >
Agreed but I don't really feel like rewriting part of the KDE shutdown code, at least no right now. Anyways phonon still needs to play files , in Amarok for instance so a null backend just won't do it. But I agree that the shutdown not working because it can't play a sound is just plain stupid. It gets even better by the way , if you do have a phonon backend and that doesn't work it still won't shut down :D. Took me quite a while to figure out it wasn't shutting down because of phonon issues.... I didn't really think that an audio framework was related to shut down. Anyways, poor code but it does work now in Frugalware and we can live with it I guess. _______________________________________________ Frugalware-devel mailing list [email protected] http://frugalware.org/mailman/listinfo/frugalware-devel
