> 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. _______________________________________________ Frugalware-devel mailing list [email protected] http://frugalware.org/mailman/listinfo/frugalware-devel
