media-sound/rhythmbox-0.12.8-r1 when built with the python USE flag always requires dev-python/mako. Right now the ebuild requires it only when webkit USE flag is activated. dev-python/mako is needed in order the "Context Pane" plugin to work. Here is the error when the "Context Pane" plugin is activated and mako is not present (rhythmbox built with: USE="cdr daap gnome-keyring ipod libnotify lirc musicbrainz nsplugin python udev upnp -debug -doc -hal -mtp -test -webkit"): Traceback (most recent call last): File "/usr/lib64/rhythmbox/plugins/context/__init__.py", line 30, in <module> import ContextView as cv File "/usr/lib64/rhythmbox/plugins/context/ContextView.py", line 33, in <module> import ArtistTab as at File "/usr/lib64/rhythmbox/plugins/context/ArtistTab.py", line 36, in <module> from mako.template import Template ImportError: No module named mako.template (rhythmbox:14217): Rhythmbox-WARNING **: Could not load plugin context (rhythmbox:14217): Rhythmbox-WARNING **: Error, impossible to activate plugin 'Context Pane' I upload the fixed ebuild - media-sound/rhythmbox-0.12.8-r2 Reproducible: Always Steps to Reproduce: 1. emerge rhythmbox with: USE="cdr daap gnome-keyring ipod libnotify lirc musicbrainz nsplugin python udev upnp -debug -doc -hal -mtp -test -webkit" 2. Start Rhythmbox -> Edit menu -> Plug-ins 3. Try activating "Context Pan" plug-in Actual Results: Plug-in crashes with the error described above. Expected Results: Plug-in should be activated.
Created attachment 261845 [details] Fixed ebuild so mako is always required when python USE is active
mako is useful only with webkit which powers the context panel so the dependency is correct.
(In reply to comment #2) > mako is useful only with webkit which powers the context panel so the > dependency is correct. > Yeah ok... But plugin is still not working/crashes when webkit flag is not used... This is definitely a bug (though more like an upstream one like wrong package checks etc)... So why not remove the plugin from ${D} if (! use webkit) ??? Like this for example: src_install() { gnome2_src_install find "${D}/usr/$(get_libdir)/rhythmbox/plugins" -name "*.la" -delete \ || die "failed to remove *.la files" if ! use webkit ; then rm -fR "${D}/usr/$(get_libdir)/rhythmbox/plugins/context" \ || die "failed to remove context plugin files" fi } BUG renamed and reopened. The ebuild attachment - made obsolete.
Comment on attachment 261845 [details] Fixed ebuild so mako is always required when python USE is active DEPENDS ok, though "context" plugin crashes without mako and pywebkitgtk and needs removal if "-webkit" flag
I feel dirty removing plugins just because users don't want the dependencies. I guess I'll have to bite the bullet eventually, it just makes to ebuild more complicated to maintain.
> I feel dirty removing plugins just because users don't want the dependencies Will there be any difference compared to a removed(not build in fact) plugin because of a used "--without-OPTION"?...... aren't the use flags created in favour of users after all?... Which means if a user doesn't want a feature/dependency and he disables it with the help of a use flag, he should not have crashing/not working features in the application... And btw this ebuild really needs some cleanup... that is if we accept the "theory" that the user should have full control over his app building... For example: It turns out that 'upnp' and 'webkit' flags are totally useless... Because if python is enabled these plugins will be build no matter what the USE flags say... BUT.. when the user tries to enable the plugins at runtime... they'll fail (if the flags are disabled - as in this bug)... And this should not happen... This is an upstream problem too btw. The other situation is when python is disabled but the two flags enabled... the user will get an ewarning... that he should read (and how many users actually read these is another topic)... but he will not have the plugins available at least...
adjusting priority. Most of the problems you mention will be fixed by bumping the ebuild to EAPI 4 but this is not happening for 0.12 series as it is stable already.
*** Bug 363015 has been marked as a duplicate of this bug. ***
*** Bug 364687 has been marked as a duplicate of this bug. ***
*** Bug 371681 has been marked as a duplicate of this bug. ***
*** Bug 368747 has been marked as a duplicate of this bug. ***
Please try with 2.99.1 (0.12.x is completely dead and unmaintained) and it's using eapi5 new features
