KRemoteControl is a KDE frontend for the Linux Infrared Remote Control system (LIRC). But LIRC is not set as a dependency of kremotecontrol ebuild.
The depend variable is used to declare all packages that need at unpack/patch/compile time and lirc is not needed, infact: amd64box ~ # eix -I --only-names kremotecontrol kde-base/kremotecontrol and amd64box ~ # eix -I --only-names lirc amd64box ~ # Also it is not needed at runtime because is not linked to lirc. Scanelf reports (after installing lirc): kde-base/kdelibs-4.9.3 kde-base/kremotecontrol-4.9.3 sys-devel/gcc-4.5.4 sys-libs/glibc-2.15-r3 x11-libs/libX11-1.5.0 x11-libs/libXtst-1.2.1 x11-libs/qt-core-4.8.2 x11-libs/qt-dbus-4.8.2 x11-libs/qt-gui-4.8.2 x11-libs/qt-script-4.8.2 x11-libs/qt-xmlpatterns-4.8.2 I hope this is clear now.
Ok, it's not linked, but kremotecontrol without lirc is a frontend to nothing. It' useless. Am I wrong? Just like smplayer without mplayer. P.S. how you use scanelf to retrieve runtime dependencies?
Thanks, fixed in CVS and git + 27 Nov 2012; Michael Palimaka <kensington@gentoo.org> + kremotecontrol-4.9.3.ebuild: + Add runtime dependency on app-misc/lirc wrt bug #444782, and update + DESCRIPTION - lirc is the only supported backend. http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commit;h=e75a4f007b2fa0685cd810d9fbbb6b9098cf2b61
(In reply to comment #2) > P.S. how you use scanelf to retrieve runtime dependencies? I think ago uses a script like this: qlist kde-base/kremotecontrol | xargs scanelf -L -n -q -F '%n #F' | tr , ' ' | xargs qfile -C | sort -u
(In reply to comment #4) > (In reply to comment #2) > > P.S. how you use scanelf to retrieve runtime dependencies? > > I think ago uses a script like this: qlist kde-base/kremotecontrol | xargs > scanelf -L -n -q -F '%n #F' | tr , ' ' | xargs qfile -C | sort -u Thank you
I don't have any infrared devices on my laptop and I believe the vast majority of KDE users have none in their machines either. In fact, less than 3% of PC's have an infared device attached to them. For years I've installed the KDE suite by using the kde-meta package which in turn pulls in the other most commonly used KDE packages in the suite. Now with this change in the kremotecontrol.ebuild I've got an issue because lirc is getting pulled into the emerge cue unnecessarily with no way to block it from installing short of uninstalling the kde-meta package, then adding every sub kde-meta package i.e., (kate, kdeadmin-meta, kdeartwork-meta, kdebase-meta, kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta, kdenetwork-meta, kdeplasma-addons, kdetoys-meta, kdepim-meta) and every package within the kdeutils-meta minus kremotecontrol individually. I don't find this to be a very acceptable solution. Are we becoming Microsoft, Red Hat or Ubuntu, where we are all forced to install unnecessary bloat in order to satisfy the 3% of users that MIGHT need a package? Instead, a better solution would be to add the lirc "use" to the kdeutils-meta package like we do with cups and floppy. This way all one has to do if they have an infared device is add the lirc "use" to draw in both kremotecontrol and lirc. This to me seems like a more elegant solution than forcing the vast majority of us who don't have infared devices to install packages we don't need. TIA
If you don't have infrared you do not need kremotecontrol as you do not need lirc, so the best way is to not install both of them. But It's necessary lirc for kremotecontrol to work. So, the lirc USE in kdeutils probably is the best solution, as it was in the old kdeutils-meta-3.5.10: http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git;a=blob;f=kde-base/kdeutils-meta/kdeutils-meta-3.5.10.ebuild;h=dfca7176063fdda6740490c73a70edfa2100c20f;hb=HEAD lirc pulled in by kremotecontrol pulled in by kdeutils-meta + lirc
Created attachment 330852 [details] modified kdeutils-meta ebuild This modified ebuild only installs kremotecontrol and lirc if USE="lirc"
I uploaded this modified ebuild for kdeutils-meta that only installs kremotecontrol and lirc if USE="lirc" is selected. I've tested it in my overlay and it works as expected. I hope it is accepted into the tree ASAP. TIA
I opened a new Bug #445150 report requesting the above modified ebuild be added to the tree. Ciao
