I don't have an infrared port on my PC, nor am I likely to get one. Therefore, it doesn't seem appropriate (or in the gentoo spirit) that I should be forced to install lirc in order to use xine. Judging from bug #13241, however, there are no plans to have a separate use flag for lirc. The mplayer ebuild looks for /usr/include/lirc/lirc_client.h to determine whether lirc is installed, and hence whether to build mplayer with lirc support. I have attached a xine-ui ebuild which does the same. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 9180 [details] xine-ui ebuild that looks for lirc before configuring with lirc support
Fact is, you dont need to check for this. Xine checks if you have lirc, and enables it. Another solution ( bug 17186 ) is to put: lirc? ( app-misc/lirc ), but it is redundant
*** Bug 17186 has been marked as a duplicate of this bug. ***
There is no lirc USE variable right now, so we can't depend on it. If you guys feel that there is need for the USE variable, please open a separate bug report for it (just for the USE variable). Tristan, your solution is not acceptable because it will not install lirc for someone who may want it, but doesn't have it installed. Lirc functionality is optional in Xine, but I don't see any harm in installing lirc for everbody: you don't have to use it, and it is not a very large package to be a concern.
oh come on! if someone knows they have an infrared port, they WILL emerge lirc by themselves, and xine/mplayer will install support! You shouldn't force down our throats something that most of us don't have, but since i dont have vote in this, i will request an use variable to get this crap removed. The mplayer ebuild does not enforce lirc, neither should xine and gxine (please DONT screw up mplayer too!!!!)
I agree. I thought that the whole point of gentoo was that the user could choose was installed. Besides, lirc is hardly a very common package - how many people have infrared ports (especially now that bluetooth is getting more popular). Obviously a USE variable would be better, but the solution that I posted is good enough for the mplayer ebuild, so I don't see why it can't be used for xine.
Francisco, don't overreact. ;) Surely no-one is "forcing anything down your throat". You should learn to argue a point calmly. Use flags are a nice mechanism, but once you have too many of them, their utility starts to decline. Personally, I vote for having "lirc" USE flag; my point was that currently there is no such flag, so I cannot fix this problem "the right way", and I chose not to do it any other way. Currenlty we are discussing adding a "lirc" flag in the gentoo-core mailing list. If the flag comes into existence, I'll gladly utilize it in the xine-lib ebuild. Intil then, I'm sure that you'll be able to continue enjoying xine, even if it dgragged the lirc package into your system.
1) emerging *xine installs lirc, forcing it. emerging mplayer does not. If i do have lirc installed, both install lirc support accordinly. So, it shouldn't be there. 2)I dont want a new flag myself, i want lirc removed from the ebuild, just like mplayer does. This is bloat, pure and simple 3)Hell, i am enjoying xine and mplayer without lirc. I can remove a line from an ebuild or use --nodeps, thank you. But what about the others, who don't much what is going on their systems? If you please post this bug into the mailing list discussion maybe more people will back me up
The fact that mplayer does it some other way does not neccesarily mean that it's the right way. What's bloat for you is a feature for somebody else. Having lirc installed for you is a lot less problematic than not having it installed for someone with an IR port (xine will still run properly with the package installed, but lircd not running). Sometimes you have to compromise, and this is one of those cases. If you feel so strongly about having lirc on your system, there is nothing stopping you from creating a custom ebuild for xine-lib. Nobody is forcing you to use our ebuild; hell, nobody is even forcing you to use xine or Gentoo. :) This is what I meant that nobody is forcing you; sorry I have to spell it out. And the ones "who don't much what is going on their systems" won't notice that lirc is installed, since the things will continue to work for them, so I don't think that the problem is as horrible as you are describing it.
mplayer and xine share the same code referring to the configure detection of lirc, so why does the build should be different in this matter? If i install lirc, it's because i have an ir port. Would you install the nvidia drivers if you had an ati card? It's the same example. Try forcing an user that! :) Yes, i know nobody is forcing me to use gentoo or the xine ebuild, but it's not like i'm asking you to code something very hard, i can even submit the patch if you want :) That's not the issue here... And, lastly, the ones with lirc installed without the ir port, "who don't much what is going on their systems", may file a bug someday when they run xine and see xine trying to open up the ir port and get a big "Permission denied" message, thinking their program doesn't work or something
Fixed in the CVS.
