I like the kipi-plugins, but I doesn't need e.g. any video or digikam functionality in a picture viewer. So I installed the kipi-plugins without media-libs/libgphoto and media-video/mjpegtools dependencies. It will be really helpfull if they can be used optional by checking some USE FLAGS (e.g. "gphoto2" and "mpeg") in the kipi-plugins ebuild. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: All kipi-plugin parts are installed Expected Results: Only the needed kipi-plugin parts should be compiled and installed
If you provide the needed Makefile patches and they get accepted upstream, it's easily possible.
Created attachment 55444 [details, diff] Patch to take care of more USE Flags for the kipi-plugin
I don't now why to change the kipi-plugins Makefile. I applied a patch for the ebuild with the changes to handle more USE Flags. I'm not an ebuild expert, but the patch looks good to me or missed I something? BTW I forgot to add another optional kipi-plugin dependency. The following line should be add to the ebuild, too: tiff? ( libtiff )
>I don't now why to change the kipi-plugins Makefile. Because you may have an optional dependency installed for a reason, but don't want to have it in your kipi-plugins. The autodetection code would add the support, but Portage won't add the dependency as needed. We need strict configure options for all optional stuff without any overriding autodetection code. This is one condition for having proper reverse dependency checking in Portage in some distant future. Just adding a use flag does not suffice. >tiff? ( libtiff ) Right. I always implied it'd be a hard dependency of kdelibs, but that changed a while ago.
Thanks for your fast answers. >>I don't now why to change the kipi-plugins Makefile. > >Because you may have an optional dependency installed for a reason, but don't >want to have it in your kipi-plugins. The autodetection code would add the >support, but Portage won't add the dependency as needed. We need strict >configure options for all optional stuff without any overriding autodetection >code. This is one condition for having proper reverse dependency checking in >Portage in some distant future. Just adding a use flag does not suffice. Reverse dependency checking sounds great, but it doesn't help me at the moment. Why not split it in two parts. The current kipi-plugin version doesn't support a configuration of all dependencies, so at the moment USE Flags could be added like I described earlier. Then I will add a Bug-Report for kipi-plugin at kde.org. If they change there configure in a next version the second part can be added to the ebuild. Are configure options mandatory for using USE Flags? I found a lot of ebuilds where all or some USE Flags are used in conjunction with autodetection (e.g. xine-lib, kaffeine, amarok, mkvtoolnix). At last a pragmatic idea: Instead of changing the configure scripts in many projects why not add support for autodetection handling to portage (e.g. with a new ebuild command). Okay the emerged package could have more features than wanted but this is better as to add more features and more packages than wanted as done with the current kipi-plugin ebuild.
>Why not split it in two parts. There are enough broken ebuilds in the tree. If you want it now, put it in your overlay. On hold until someone comes up with patches.
bugzie
Checked the ebuilds. Looks fixed and flaged.
