$ vlc VLC media player 0.8.6 Janus [00000305] main dialogs provider error: no dialogs provider module matched "any" [00000302] skins2 interface error: no suitable dialogs provider found (hint: compile the wxWidgets plugin, and make sure it is loaded properly) [00000302] skins2 interface: skin: VLC 0.8.5 Default Skin author: aLtgLasS [00000381] main dialogs provider error: no dialogs provider module matched "any" [00000302] skins2 interface error: no suitable dialogs provider found (hint: compile the wxWidgets plugin, and make sure it is loaded properly) On a side note, installed desktop file points to wxvlc even if the ebuild is compiled without USE="wxwindows", so it doesn't work.
indeed, the skins2 interface requires wxwidgets for dialogs like preferences, open file, media info, etc. ebuild should check for the use flag combination of skins and not wxwindows and abort, or at least tell you that you're about to waste 10 minutes installing a mostly crippled program.
*** Bug 164407 has been marked as a duplicate of this bug. ***
vlc will now die if skins are wanted but not wxwindows. vlc.desktop is removed if not using wxwindows. thanks for reporting.
Created attachment 112239 [details, diff] vlc-0.8.6_p18636.ebuild.patch I would like to ask to have these USE flags (wxwindows and skins) not be tied to each other. If USE=skins would set DEPEND=*wxGTK, that should fix the problem IMHO. Forcing users to choose certain USE flags is a rather awkward way of satisfying a package's dependencies, especially when forcing users to actively choose wxGTK. In an ideal world, USE flags should never depend on other USE flags, and in this fortunate case, they need not depend on each other.
...
With this patch this will enable/disable the one that is given last to configure : try to run : ./configure --disable-wxwidgets --enable-wxwidgets and then : ./configure --enable-wxwidgets --disable-wxwidgets the former will build wxwidgets and the latter not. moreover, if use="-wxwindows skins" is given, WX_CONFIG will not be set. This requires at least to do some $myconf tricks since I'm not aware of any way to do OR's in use_enable (something like : use_enable (skins || wxwindows) wxwidgets might work? having a look at ebuild.sh suggests me that no, but perhaps there are some tricks I dont know). Agreed that those die's are really ugly, forcefully enabling a feature requires at least that the user is told about it, and imho, in a perfect world I would be able to specify internal use dependencies in the ebuild with something like : USE_FORCE="skins? ( freetype wxwindows )" that would enable those useflags if skins is enabled and print a notice that it has been done so.
Comment on attachment 112239 [details, diff] vlc-0.8.6_p18636.ebuild.patch As noted above, this approach doesn't work. You can either drop USE=skins altogether and always enable it w/ USE=wxwindows or wait for upstream to switch to QT4 (0.9) and get rid of this goddamn wx* thing :P
(In reply to comment #7) > You can either drop USE=skins > altogether and always enable it w/ USE=wxwindows I'd rather keep the die uglyness than loosing some flexibility. > or wait for upstream to switch > to QT4 (0.9) and get rid of this goddamn wx* thing :P Afaik, 0.9 will add the qt4 gui but will not kill the wxthing. But, this internal useflag dependency can be workarounded (spell?) by a mimic of a clean internal use dependency in portage and we'll get rid of those dies without problem, but this would add even more complexity to the already too complex vlc ebuild. I'd prefer that this gets into portage, but I'm not 100% sure if it's possible. And perhaps it has already been done ;) @portage team: Any idea about this ? Is this already done ? Is this not "politically" possible for now ? Is this a good idea ? Is this possible to implement it ? internal use depping seems much more simpler than use deps to implement, so if the only problem is that you don't have time to do it, I'll be happy to start hacking it ;)
(In reply to comment #8) > I'd rather keep the die uglyness than loosing some flexibility. Well, I don't see much flexibility in redundant flags; this is an upstream bug a.k.a. half-assed implementation of some GUI that someone gave upon later on apparently. > @portage team: Any idea about this ? Is this already done ? Is this not > "politically" possible for now ? Is this a good idea ? Is this possible to > implement it ? No, it's not done. See phpconfutils.eclass for a fugly workaround that I'd rather not repeat anywhere else in the tree. Drop the skins flag, it doesn't make sense as a separate one in the way it was implemented upstream.
(In reply to comment #6) > USE_FORCE="skins? ( freetype wxwindows )" One way to express something like this would be to package.mask USE combinations that are not allowed. For example: media-video/vlc[skins][-freetype][-wxwindows] (In reply to comment #8) > @portage team: Any idea about this ? Is this already done ? Is this not > "politically" possible for now ? Is this a good idea ? Is this possible to > implement it ? > internal use depping seems much more simpler than use deps to implement, so if > the only problem is that you don't have time to do it, I'll be happy to start > hacking it ;) I think that pretty much everybody thinks USE deps will be nice to have (I haven't heard anybody arguing against having USE deps). I'm planning to write a new dependency resolver very soon with the goal of solving many of the bugs listed as dependencies of bug 155723 (including USE deps, bug 2272).
(In reply to comment #10) > (In reply to comment #6) > > USE_FORCE="skins? ( freetype wxwindows )" > > One way to express something like this would be to package.mask USE > combinations that are not allowed. For example: > > media-video/vlc[skins][-freetype][-wxwindows] Very interesting, I'd have prefered the other way (forcing a use flag if another one is set) but that would replace the die's (but have the same effect). > I think that pretty much everybody thinks USE deps will be nice to have (I > haven't heard anybody arguing against having USE deps). I'm planning to write > a new dependency resolver very soon with the goal of solving many of the bugs > listed as dependencies of bug 155723 (including USE deps, bug 2272). Use deps are a nice thing for sure, but so far what I've understood of it is that it is the ability to depend on a package merged with a certain useflag. Here the problem is simpler which is to just set dependencies upon its own useflags (and most likely depending on itself merged with a certain useflag wont work) like it is done in the phpconfutils eclass. Zac, if you could give the ability to specify some useflag logic in the ebuilds at the same time that would be great ;) Anyway for now, if I remove the die's in vlc that will be something in the fashion of what Jeroen suggested at the first place, taking care of all the possible useflag combinations.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #6) > > > USE_FORCE="skins? ( freetype wxwindows )" > > > > One way to express something like this would be to package.mask USE > > combinations that are not allowed. For example: > > > > media-video/vlc[skins][-freetype][-wxwindows] > > Very interesting, I'd have prefered the other way (forcing a use flag if > another one is set) but that would replace the die's (but have the same > effect). FWIW, it can also be expressed via package.use.force with use deps: media-video/vlc[skins] freetype wxwindows > Use deps are a nice thing for sure, but so far what I've understood of it is > that it is the ability to depend on a package merged with a certain useflag. > Here the problem is simpler which is to just set dependencies upon its own > useflags (and most likely depending on itself merged with a certain useflag > wont work) like it is done in the phpconfutils eclass. Zac, if you could give > the ability to specify some useflag logic in the ebuilds at the same time that > would be great ;) An extension to ebuild metadata like this needs to be well thought out and have lots of peer review. At a minimum, it would be worthy of a discussion on the gentoo-dev mailing list (maybe a GLEP is overkill).
> An extension to ebuild metadata like this needs to be well thought out and have > lots of peer review. At a minimum, it would be worthy of a discussion on the > gentoo-dev mailing list (maybe a GLEP is overkill). Yep, I was thinking about it a little bit more. Such useflags dependencies will have to be restricted in some way, if you allow everything that will lead to solving a SAT problem for the useflags, what is not wanted here I suppose. By restricting it, that will have more or less the same expressiveness power as what you cited above: package.mask and package.use.force with use depends. As you already have to solve an np-complete problem with dependencies, use dependencies will make it even harder, so there is only one thing more I can say : Thanks Zac ! I've added the bash & myconf stuff to vlc ebuilds in order to handle skins dependencies by forcing truetype & wxwindows when skins useflag is enabled, so this one is fixed now ;)
(In reply to comment #8) > Afaik, 0.9 will add the qt4 gui but will not kill the wxthing. Just a follow-up - yeah, 0.9.0-svn configure scripts just dies now with an error if you do --enable-skins2 --disable-wxwidgets (which is should have been doing all the time in the first place). Anyway, it has QT4 GUI working like a charm (in fact wxwidgets is considered deprecated in this version), so I finally got rid of wx* altogether, yay!
